Clinical database of classified out-patients for tracking primary care outcome

ABSTRACT

A computerized medical database system for the standardized recording and tracking of out-patient care by the simulation through existing software of multiple facets of a typical primary care clinical environment. 
     Central to the system&#39;s data processing are office visit records as the primary vehicle for encoded data input and a chronic diagnosis classification table for ranking out-patients into separate, prioritized diagnostic categories. Integrated with both in a relational database are other files storing distinct but related clinical attributes of both the transactional and inventory type. The former, as event-based, include emergency room, medicine activity, specialist, lab tests and an office visit-derived or intermediary file while the latter type, as a fixed pool of clinically descriptive data elements, include long and short-term diagnosis, physical signs and symptoms and a generic medication list. 
     The data processing is of three kinds; data entry of office visit, one master medical for each out-patient and lab test result records, data query for obtaining summary-type, narrowly focused information for a single or group of related out-patients and, thirdly, the compilation of data from office visits for reporting various clinical results. 
     Some of the latter type processing, using sets of clinical criteria including diagnostic category for specific record selection, include detecting and justifying excessive office visits, determining lab test overusage, monitoring physician activity during episodes of protracted illnesses of differing severity and the printing of physical, medication and lab test results from the same office visit.

This application is a continuation of Ser. No. 07/276,414 filed Jan. 23,1989 abandoned.

BACKGROUND TO THE INVENTION

American medical care has been placing this country under a tremendousfinancial strain and will continue to absorb an increasingly highershare of its resources into the indefinite future. Over the past 20years its average cost increases, primarily of the institutional kind(hospitals, lab tests etc.), has risen annually at over twice the rateof inflation compared to the rest of the economy and will remain for theforseeable future as the most expensive sector of our consumer-drivensociety.

The reasons are chronic and multiple and in most cases simply reflectand stem from cultural features unique to 20th century American society.For example, an increasingly ageing population that will continue toconsume a disproportionate share of our clinical resources, increasedleisure time by all age groups that allows for such discretionaryindulgences as more `health care` consumption that only creates moredemand on a medical care system that is already oversubscribed to, thevirtual doubling of american medical school graduates since the early70's along with almost no effort to limit the entry of foreign medicalgraduates which in itself greatly expands the size of an already veryelastic medical marketplace (i.e. the number of cars or refrigerators webuy is pretty fixed but not the number of times we might see a doctor).There is also the ever-present fear by doctors and hospitals of costlymalpractice litigation that increases both front-end costs by higherinsurance premiums and higher day-to-day costs by the defensive use ofexpensive tests and high-tech procedures done simply to lessen the riskof and protect against any future lawsuits.

In the wake of this dilemma in an open and free society several measureshave been initiated separately and independently over time to curb costsand even improve quality of care. Unfortunately none have succeeded andthe costs continue to skyrocket. That's primarily because none haveaddressed how we actually examine in a precise and large scale way howthe daily practice of medicine is delivered and what the resultsactually are, especially on a comparative basis.

Up until now the `solutions` have only been regulatory andadministrative in nature that in fact only interfere in the naturalpractice of every day medicine without a mechanism for actuallyassessing what has happened on a large-scale and precise analyticalbasis. And in many cases has only led to divisiveness and polarizationamongst health care providers.

For example, the corporatization of American medicine by HMO's that usehigh-powered ad techniques and the `magic` of fixed pre-payments forsubscribers as a way to control costs while never publicly acknowledginghow their member doctors are gently co-erced to hold the line in thetrenches by rationing through the limiting of tests and even officevisits. But several HMO's, in Massachusetts for example, have alreadybegun to experience financial problems and have been forced to merge dueto an oversubcription by the elderly and the resultant encounter ofgreater than projected costs through vast and unanticipated increases inthe use of resources. Also, despite the promise of cost reductionthrough so-called health care competition, the appearance of `alternatehealth care providers` like nurse practitioners and physiciansassistants has been a failure in controlling costs primarily because ittoo only increases the size of the medical marketplace while alsocausing confusion over who does what, turf battles and duplication ofeffort. It has also caused a massive over-concentration of health careproviders since these paraprofessionals always seem to locate in areasthat are already heavily populated by doctors. As another example of thefailure to control the cost of something as unpredictable andcomplicated as medicine, and therefore its consumption, is the lack ofmeasurable success with DRG's or Diagnostic Related Groups. Basically,they are a method for assigning costs and fees to certain diseasecategories that's used by hospitals and insurance companies forpre-determining how much they should spend during a hospitalization. Assuch, they only address one aspect of medical care; hospitalization, areunable to examine on a large and precise basis the individual practicesof doctors on a comparative basis and they create artificial boundariesthat are overly and too neatly drawn between medical conditions that areoften related and overlap clinically, and are naturally unable to takeinto account the many hidden uncertainties that frequently appear inclinical medicine and as such deal poorly if at all with unforseencomplications. They have been operative for some time but they havefailed to control costs while adding nothing to the quality of medicalcare.

None of the above measures have succeeded because they are superficial,politically expedient and often costly in themselves due to theirpromotion of additional regulations and new agencies that increase theadministrative and bureacratic cost of medical care. Unfortunately noneof them are designed to look directly at and examine what actuallyhappens on a day-to-day basis at the level of the patient-physicianencounter at that point in the medical care system that hastraditionally been the most responsible for eventually determining howmuch we will spend; the primary care, general practice, out-patientsetting. Until now, no one has bothered to look at what happens and whyat the level of the primary care out-patient physician practice whereall the medical-consumer habits, trends and diseases originate.

Primary care, out-patient medicine is the most frequent point of contactin the medical care system and until a method for its precise andlarge-scale analysis is found, a rational basis for cost control inmedicine will never be obtained.

What is therefore needed is an automated method for looking at whatdoctors do, their observations, tests, treatments, and diagnoses, etc.,on a daily basis to a large, organized and well defined population ofout-patients in a primary care setting under clearly spelled out anduniform conditions and circumstances. A kind of primary care `audittrail system` that uses the power and flexibility of the computer tocollect, store and process data under pre-defined conditions that enableapplying uniform standards of analyzing care by doctors to patients inregard to both outcome and resource utilization.

My computer-based system, with its database and programs, is a model fordemonstrating the feasibility of doing just that. It is aninformation-management-system for the analysis of clinical dataprocessed by the computer in such a way as to reflect what has happenedduring the natural and traditional way out-patient medicine isconducted. It records the identical set of data under an identicalmethod for all patients and then processes that data for specific groupsof out-patients according to uniform criteria that create specificaspects of primary care medicine through the `customized` design ofcomputer-program software.

Both out-patients and their doctors are members of the database. Eachout-patient is placed into one of three diagnostic categories for thepurpose of selective data processing that depends upon the single orcombined value of up to three chronic diagnosis any one patient mayhave. Other elements of the system are a family of related files thatstore separate, related aspects and items of clinical medicine, many ofwhich are linked to each out-patient as individual clinical attributesthat contribute to the total medical profile of each out-patient. And aswith other types of more common database systems, this one has twogeneral types of files; transactional and inventory. The former areevent-based, its records accumulating over time through data entryprograms and how many of them any one patient has depends upon thecondition or disease activity of that out-patient. On the other hand theinventory type files contain a fixed number of records and consist ofdata items that are used to affix those clinical attributes appropriateto any out-patient, i.e. symptoms, diagnosis, medicines, etc. that canclinically define them at any point in time.

Such a database, with its integrated set of related files of both types,then serves as the informational base for the processing operationsconducted by a separate set of computer programs (other than the dataentry ones) that are designed to simulate or mimic aspects or conditionsof out-patient medicine. With such distinct and `logical views` thatcreate special facets of out-patient clinical medicine drawn by suchprograms that now process that centralized pool of integrated clinicaldata stored in separate files, it becomes possible to apply precise andlarge-scale analysis uniformly from an outcome based perspective whilealso being able to look at what doctor did what and for what reason.Under uniform and standardized conditions you can now analyze clinicalresults about any number of out-patients from both the same diagnosticgroup or make comparative results between different diagnostic groups.And you can establish a level of priority in the analysis of results andresource usage that includes a measure of expectation by the selectiveprocessing of different diagnostic groups or out-patients within anygroup that differ by chronic diagnosis.

In short, my model database system collects and loads the same set ofclinical data in the same way for out-patients classified according todiagnostic groupings. The data reflects the natural activity thatnormally occurs every day in a primary care setting. The data is thenprocessed by an associated set of programs that select for certainclinical conditions and criteria that by design create special aspectsof out-patient medicine. For example, viewing lab test results orderedduring a special type of office visit in conjunction with other salientclinical data observed during that same visit that then enabledetermining if said lab tests ordered were justified in view of whatthat doctor observed about that out-patient. As another example, acomputer program in this model system enables one to look at bothsymptoms and medications ordered during a special type of office visitfor a group of patients with the same chronic diagnosis who are beingcared for by the same doctor. In this way analysis is possible underconditions uniformly applied to groups of patients and doctors fromhighly focused aspects of out-patient, primary care medicine that makesuch analysis easy because it creates identical reference points forcomparisons.

Such a model system, as outlined in this specification, can at least beused for one important purpose; to supplement the traditional`non-system` of medical record keeping. It can remedy the current systemwhich, as everyone knows, is non-integrated and non-standardized, whichis manually based and highly individualized from physician to physiciandepending upon that physician's personal bias or style. And as such istotally incapable of being viewed from specially created clinicalcircumstances through program design for special emphasis or on a largescale basis that can offer comparative analysis.

My model, computer-based system doesn't have to replace anything and itdoesn't have to interfere with the way things have been done. But itoffers, by way of proven technology, a new, different way of looking andanalyzing the outcome and resource usage at the most frequent andcritical point of our health care system from the long-term point ofview: the primary care, out-patient setting.

SUMMARY OF THE INVENTION

A computerized clinically oriented out-patient medical database for theretrospective and outcome-based tracking and monitoring of both qualityof care and the proper utilization of clinical resources from a varietyof medical aspects and conditions that characterize a primary caresetting.

This model `audit trail` system, its data pool, file relationships andprograms that process the data to load, manipulate, print and query theclinical data along with its method of triaged data processing byout-patient diagnostic categories, now enables the unlimited versatilityof storing, accessing and reporting computer-based clinical data forclassified out-patients, both individually and by groups, and from avariety of medical aspects or clinical perspectives that allow forspecial emphasis or particular focus. For example, detecting the overuseof office visits by out-patients pre-selected by diagnostic category,monitoring the actions by physicians during protracted episodes ofout-patient illnesses, and the separate reporting of physical,medication and lab test results from the same office visits selected bythe primary reason, acute or chronic diagnosis, for the office visit.

Such a system can readily supplement the only other current, highlyindividualized and vagaried record-keeping `non-system` doctors havetraditionally used. An anachronism in today's computer age since the wayin which patient data is viewed and expressed often reflects personalphysician biases. For instance it is always looked at on a patient bypatient basis, isolated and in a non-comparative way, manually andwithout the capacity for special or particular clinical emphasis and inthe absence of fixed and uniform standards that enable legitimatecomparisons amongst and between the same and differently classifiedpatient groups.

The out-patients of this database would ideally be fixed adultsubscribers to a Managed Health Care Plan such as an HMO with eachpatient assigned to one of several database doctors. Upon a first recordcreation a new patient automatically classified into one of threediagnostic categories depending upon the nature and the amount of up thethree chronic, long-term diagnosis any out-patient may have. Theclassification is based upon the relative positions of that patient'sdiagnosis in reference to the other chronic diagnoses' present in atable of chronic diagnosis that contain the entire pool of diagnosisthat any database patient may have and which is arranged according to asorting of the chronic diagnosis by prognosis or clinical urgency. If anout-patient is placed into the uppermost diagnostic category of thechronic diagnosis table, it is because that patient has at least onediagnosis from that highest table category and is then ranked for thepurpose of selective data processing within the highest priority group.Since the classification enables the ranking and therefore the selectionof out-patients by diagnostic categorys into priority groups, theclassification itself serves as an initial clinical focus for manyprograms in this system's data processing because it enables anyone toview the resultant data from the kind of clear reference point thatclinical urgency or prognosis is. And therefore enabling users of thesystem to be alerted sooner and easier to the need for more immediateattention to such priority based clinical data.

After the initial out-patient record selection, each program thencontains deeper level code for specifying further criteria andconditions that further limit the data generated to a particular andnarrow aspect of out-patient medicine. For example, a program mightfirst select only office visit records of those out-patients from thehighest ranked diagnostic category and then further limit the clinicalaspect to only cardiac patients within that highest priority group,excluding for instance patients with fulminant lupus or bad liverdisease, etc.. Then through additional program code it may further limitthe clinical aspect or condition to only those office visit (records) inwhich those cardiac patients were documented to be very symptomatic(ill). And then, as a final criteria or facet, to complete theparticular clinical `configuration`, the program may only select thephysical data (signs and symptoms) observed and any medication changesenacted by the physician during those office visits, and excluding otherdata from being processed in this program that is also present in eachoffice visit record. And it is then possible to limit the informationgenerated to only a few database doctors or even just one in particular.

This kind of `configurating` in which narrow and specific aspects ofout-patient primary care medicine can be drawn by individual facts beingcombined together through sequential program criteria is, thanks todatabase software, a process that is potentially unlimited in itsversatility.

It should also be noted that this computerized medical database system,with its adaptation of business database software, is analogous to astandard and more familiar computerized accounts receivable section of amail ordering business, a traditional application for database software.In the first place, the office visit record parallels the pivotal natureof the orders/invoice record since they both represent each system'smost frequent, initial contact point as principal data entry processesand the primary source from which other related data records aregenerated. Secondly, and as a derivative of the first example, both themedicine-activity and lab test records are similar to apayments/financial record since they reflect actions subsequent to theinitial, respectively, office visit and the orders/incoice encounters.

Thirdly, the system medication and physical data files are bothanalogous in in purpose and function to an inventory or parts file. Theyboth contain a fixed number of `stock` or attributes that reflect thedistinct nature of the two systems; clinical features of patients in theformer and the consumer choice of customers in the latter. Lastly, theanalogy between the master medical record and the customer record sincethey contain both current and biographical data for use as referenceinformation with other data for each individual patient or customer.

A full elaboration of the features and functions of this invention arefound in the description section of the specification. There is acomplete narration of the preferred embodiments as represented by theprogram flow diagrams of FIGS. 17-55 and another set of descriptionsthat refer to the drawings of FIGS. 1-16 and 56-150 which include boththe system's data files and sample input/output data used with andgenerated by the system's computer programs illustrated by FIGS. 1 and2.

BRIEF DESCRIPTION OF THE DRAWINGS (BDD)

Referring to FIG. 1, a complete list of the system's computer programs(data processing routines) grouped into three categories. The maincalling programs are on the left with each of it's subroutines to theright. One subroutine may be associated with more than one main callingprogram and any one main calling program may have more than onesubroutine. The top group are intermediary routines that compile datainto new, intermediary records, the middle group are data entry routinesand the bottom group are pre-written queries. The numbers indicate themain files, illustrated in FIG. 2, that are used in each of the programslisted.

Referring to FIG. 2, an overview of the system's database files andtheir general inter-relationships during data processing. Files numbered2,7,8,9,10 and 15 are inventory in type from which a variety ofout-patient clinical attributes are obtained and used to profile eachpatient. The rest are transactional in nature and reflect the extent andnature of out-patient clinical activity over time.

Referring to FIG. 3, the classification table of chronic long-termdiagnosis, chrmedli.dbf, arranged by increasing clinical urgency orworsening prognosis in ascending order. Each out-patient is classifiedinto one of three diagnostic categories depending upon the relativepositions in the table of up to three chronic diagnosis any out-patientmay have. The first character designates to which of three diagnosticcategories that table entry belongs while the second indicates itsclinico-pathological group. The assignment of an A category diagnosis toany patient automatically places that patient in the A diagnosticcategory while the presence of three chronic diagnosis assigned to anypatient that are all from either B or C category automatically placesthat patient into the next higher (A or B) category.

Referring to FIG. 4, the system's primary care office visit record,encounte.dbf, and the principal unit of information for most of thesystem's data processing. The TYPE field is either `S` for scheduled or`U` for unscheduled and the STATUS field will contain 1 of 5possibilities numbered 1-5; 1 for normal or base-line, 2 for mildseverity of symptoms, 3 for serious, severe symptoms, 4 for clinicalimprovement from most previous visit and 5 for hospitalization orderedfrom that visit. Each record may have up to three chronic diagnosis andin cases were an out-patient has only one, that chronic diagnosis alone,by virtue of its relative position in the table, determines whichdiagnostic category that patient is to be placed in. Otherwise it isusually the diagnosis from the highest category in reference to thetable that determines the diagnostic category of that patient.

The CONDITION field of the office visit record will contain either achronic long term diagnosis or an acute short-term diagnosis as the mainor primary reason for that office visit. If it is a chronic one then itwill be any of up to three chronic diagnosis that patient already haswhile a short-term diagnosis indicates either a new as yetuncharacterized problem or possibley a complication or `flare up` of anexisting chronic diagnosis. Note the presence of four physical datafields, each as 5 digit codes for indicating up to 2 signs (findings)and 2 symptoms (complaints) with both types of physical data itemsderived from their respective signs and symptoms tables. Each officevisit record is most uniquely identified by it's six digit INVOICE fieldsince it is entirely possible that any out-patient may be seen for anoffice visit twice in the same day.

Referring to FIG. 5, the system's intermediary file, notify.dbf. As aderivative file each record is created during program execution, and thedata compiled from and representing one office visit record. The recordsare then used as basic unit of information for other system programs.Which fields contain data and the nature of that data depends upon whichprogram type was responsible for creating the notify.dbf records. Thetype of data the notify.dbf records contain consist of data compiled andwritten from the original office visit records of the encounte.dbf fileand `conditional` data depending upon the nature of the program's inputdata. Note the CATEGORY and the CODE fields. The category fieldgenerally identifies the name of the program responsible for creatingthat notify.dbf record, the diagnostic category of the out-patient whoseoffice visit record was being processed and that notify.dbf recordrepresents, clinical status of that out-patient at the time of theoffice visit, whether the visit was scheduled or not, a single lettercode for indicating the nature of what the physician did during thatvisit, whether there was any injection during the visit and by whatroute. If the program responsible for the creation of notify.dbf recordsis intended to find unscheduled office visits that occur consecutivelyby any out-patient then the above field will contain, alternatively, aninteger for indicating the consecutive number for that unscheduledvisit. If the programs that identify protracted out patient illnessesare being run then a problem resolution indicator will be encoded inthat field during processing. The data in the CODE field also dependsupon what program type is being run and therefore responsible forcreating the office visit derived records of notify.dbf It can be usedto indicate that absolute justification for an early scheduled officevisit has been found or the occurrence of one or more consecutiveunscheduled office visits for any out-patient.

Referring to FIG. 6, the system's master medical record file,medical.dbf.. There is one for each out-patient in the database and itstores both current diagnostic and medication data and background,biographical information. The data field named DIAGNOSIS1 store thatpatient's highest category diagnosis, if there are two or more diagnosisfrom the same category then the one from the highest position in thechronic diagnosis reference table occupies that field position.Similarly, any chronic diagnosis present in the DIAGNOSIS2 field will befrom a higher position in the chronic diagnosis reference table than anyone in the DIAGNOSIS3 field. The MEDFLAGN and MEDINV(N) fields are usedto indicate the last time that chronic diagnosis was assigned to thatpatient. It is a tracking device since it `points` to that office visit(record) during which that diagnostic change, addition, etc. occurredand therefore when that patient's master medical record was updated treflect that activity. Note the full documentation of all 3 possiblecurrent medications. The last 3 fields are for both the first recordedoffice visit blood pressure (top) and bottom readings) and the date ofthat master medical record creation.

Referring to FIG. 7, the system's laboratory test file, abn₋₋ lab.dbf.The date field refers to when the tests were done since the date orderedis the same date as the office visit or emergency room visit from whichthe tests were ordered. Each lab record has two invoices, one denotingit as a lab test invoice and the other for representing either theoffice visit or emergency room visit parent (or source) record thatserves as a cross-link. There are 14 fields for storing the results of14 possible types of lab tests. Each field is divided into two segments,one for storing the numeric amount with abnormal results and the otherfor the historical or parameter data for profiling the track record ofthat lab test's results over time. The parameter data consists of 3letters that encode a compilation of prior results for any abnormal testresult and is determined by obtaining such aspects of prior results asdate and value of first abnormality, date and value of last abnormality,consistency of the results and the most recent result of that test forcomparison. The three single letters that constitute the parameter datathat accompanys the abnormal result data in each lab test field are,from left to right, duration of the abnormality (chronic, acute,intermediate), intensity of abnormality and comparison to most recentresult (improved, worsened, etc.). Normal results contain only a singleletter in the first position of the parameter field and another in thefirst position of the numeric field for comparison with any most recentresult for that test.

Referring to FIG. 8, the system's short-term, acute or new problemdiagnosis table, er₋₋ list.dbf. It is identical in basic structure tothe 6 digit chronic diagnosis code except that the clinico-pathologicalgroup indicator is in the first position instead of the second. Theseentries are for alternate use in the CONDITION CODE field of the officevisit record in instances of a new clinical problem or an as yetuncharacterized complication of an established, chronic diagnosis, andunder those conditions replaces a chronic diagnosis as the primaryreason for that office visit. As in traditional record-keeping, it ismeant to serve as a temporary clinical device for describing in anon-etiological manner the nature of the new problem before and whileits exact nature and basis for it is being determined. At which pointanother or an existent chronic diagnosis for that out-patient willassigned. The entries from the short-term, acute diagnosis table, er₋₋list.dbf, may also be used for the only diagnosis field of the emergencyroom record in a similar instance when the exact and causitive nature ofthe clinical problem is not as yet fully understood or it appears to bea complication of an established chronic diagnosis of that out-patient.

Referring to FIG. 9, the medicine-activity record file namedmedicine.dbf. It is for storing up to three medications acted uponduring an office visit. The med(n) fields store the generic name of themedication and are derived from the medication inventory table, med₋₋list.dbf. The ACTION(n) field is to record the nature of the activity; achange, addition, deletion, etc. of a medication. The amount(n) fieldscan accomodate total dosage per day, tablets per day or amount and routeof any parental (injection) dosage.

Referring to FIG. 10, the system's physical findings (or signs) file ofrecords, findings.dbf. It is the data from both the CODETYPE and CODEfields of any record from findings.dbf file that is loaded onto anoffice visit record in cases where that particular physical data itemwas documented during an office visit. The first character of thecodetype field is the same indicator used with both chronic and acutediagnosis for indicating what clinico-pathological group that particularclinical attribute belongs. Also, but not used, in the same manner asboth acute and chronic diagnosis, the second character can place thephysical data item into one of three categorys depending upon itsrelative clinical urgency or priority.

Referring to FIG. 11, the system's physical symptom's (complaints)file,cc₋₋ list.dbf. Except for it storing the other type of physicaldata, it is identical in structure and purpose as the physical signstable previously described with its data elements being handled andaccessed in the same way.

Referring to FIG. 12, the system's medication inventory table, med₋₋list.dbf. It stores the complete list of medications available to thesystem in the form of their generic names.

Referring to FIG. 13 a table containing a list of surgical proceduresinvolving various clinico-pathological groups as indicated by the codedletters of the second position. It is another type of inventory tablethat provides the appropriate clinical attribute for a patient with asurgical history.

Referring to FIG. 14, two transactional type system files, surglink.dbfand treatmen.dbf. The former stores each surgical procedure any databasepatient has had with the date the surgery was done. The SURGCODE fieldwill contain any of the entries from the surgfind.dbf table. The latterfile stores records of various out-patient treatments for commonailments performed by physical therapists. The REASON field of atreatmen.dbf record will contain the chronic diagnosis of thatout-patient for which that treatment is being performed while the RXfield is a literal definition or text of the treatment being performed,i.e. `inhalation therapy`. The STATUS field is for indicating thetherapist's assessment of that patient's condition at the end of eachtherapy session. It will be either one of four possibilities, improved,same as before, worse or hospitalization recommended.

Referring to FIG. 15, the system's out-patient emergency room record,ER₋₋ ROOM.dbf. It is similar in general structure and kind of datastored as the office visit record (see encounte.dbf, FIG. 4) but muchabbreviated in comparison and with a few important exceptions. There isonly one diagnosis field which is for storing the primary reason for thepatient coming to the emergency room. It may be from either the acute,short-term or the chronic long-term diagnosis table depending upon theevaluation of the emergency room physician. The status field is forencoding one of three types of dispositions the e.r. physician willmake; follow-up office visit necessary or not and if hospitalization wasadvised. The condition field is for indicating the presence of anddegree of clinical instability of the patient at the time of the e.r.visit. As another type of transaction file, the 6 digit INVOICE field isthe emergency room record's most unique data item of identification.Referring to FIG. 16, the system's in-hospital record for anyhospitalized out-patient, pt₋₋ hosp.dbf. Like the surgical history file(see surglink.dbf, FIG. 14), it serves mainly to document its occurrenceand stores only that data that can be o use in out-patient management.There are two diagnosis fields, one upon admission and the other at thetime of discharge. They may be the same and both may be from either theshort-term, acute or the chronic, long-term diagnosis field. Thenarrative field allows for a brief synopsis of hospital course that isoptional.

Referring to FIG. 17, a main computer program entitled schedul1.prg thatdetects actual or possible overuse of office visit resources byidentifying two successive office visits of any out-patient that wereboth scheduled, completely unremarkable and uneventful, and whichoccured within a time interval as prescribed by that patient'sdiagnostic category. Upon identification, a sub-routine is called thatsearches through a set of clinical `transaction` files on that patientin order to find any data that indicate activity of some type occuringbetween those two visits that could justify that early, second scheduledvisit.

Referring to FIG. 18, a continuation of FIG. 17 that illustrates theprocess whereby a search is also conducted on the system's surgicalhistory file in order to find any data, based upon certain criteria, ofa past surgical event for that patient that could justify, in itself,that early, second visit.

Referring to FIG. 19, a subroutine entitled Searchv.prg called bySchedul1.prg that will search on 4 clinical file types (emergency room,treatment, hospitalization, lab test results) in order to find, by a setof criteria dependent upon the type of file, clinical activity occuringbetween the two office visits in question that are of such a nature asto justify the early, second visit. If and when that occurs the data isthen passed back to the main program and written to a newly created,intermediary record.

Referring to FIG. 20, a continuation of the processing of FIG. 19showing the criteria used and the decision making involved inestablishing whether or not any data found in, this case, the lab testfile indicating activity from between those two types of office visitsthat could justify the early, second scheduled visit.

Referring to FIG. 21, a main computer program entitled unschedu1.prgthat is similar in part to schedul1.prg since it also looks for officevisit overuse but with a primary emphasis upon unscheduled visits.Therefore, it identifies two types of problems; unscheduled visitsoccuring in succession for any out-patient and a scheduled one of acompletely unremarkable nature that has occured right after anunscheduled one for that out-patient that is also completelyunremarkable and within a time interval (i.e., too early) as prescribedfor that patient's diagnostic category. Upon identifying the latter, thesubroutine searchv.prg is also called from this main program.

Referring to FIG. 22, a subroutine entitled surgfind.prg called by theprogram unschedu1.prg to search for any prior surgical event of thatout-patient that by its nature could justify that early second visit ofa completely unremarkable nature. Its steps are identical to a bloc ofsource code present in schedul1.prg, but due to the size ofunschedul.prg a separate subroutine had to be written to accomodate it.

Referring to FIG. 23, a main program entitled AstatusB.prg that is oneof three in this system that identifies and processes contiguous,successive office visit records that represent a protracted out-patientillness. In this program the minimum number necessary in order totrigger processing is three since the illness, by its selection of onlycertain types of records, is only of a moderate degree. It calls asubroutine, binary.prg., for accessing encoded physical data present ineach record involved and for determining the extent and nature of theactions taken by the physician during each visit in response to theillness.

Referring to FIG. 24, a subroutine entitled Binary.prg called byAstatusB.prg that accesses encoded physical observations during eachvisit of the illness and what, if any, kinds of actions were undertakenin the treatment and management of the patient during each visit. By ascheme based upon binary numbering the subroutine compiles into a singleletter code any combination of several possible actions taken by thephysician during each visit and it also provides for pointing to otherrecords storing other clinical data emanating from that visit duringthat illness. And for the purpose of later accessing specific recordscreated as a result of this type of processing, this subroutine alsodetermines and encodes for the name of the particular main program thathas called it, since in this system there may be three that do.

Referring to FIG. 25, a main program entitled Astatus3 that is similarto AstatusB since it also identifies and processes what might turn outto represent a protracted out-patient illness but its threshold foractivation is different. It first has to identify an office visit recordwith a clinical status of 3 indicating severe symptomatology andpossibley need for hospitalization before processing begins and then itwill process all contiguous antecedent and subsequent office visitrecords of that out-patient that also indicate disease activity (i.e.,non-1 clinical status). And, like AstatusB.prg the number of recordsinvolved depends upon the length of that out-patient's uninterruptedillness. And it to calls the subroutine binary.prg for each recordinvolved.

Referring to FIG. 26, a continuation of FIG. 25 showing stepwise programlogic and note how there is movement of the record pointer in bothdirections and how the program is informed each time.

Referring to FIG. 27, a main program entitled clinevol.prg that, likeAstatusB.prg and Astatus3.prg, identifies and processes a string ofsuccessive office visit records that represent a protracted out-patientillness. The basic difference here is that processing is triggeredwhenever a non-1 clinical status record is encountered, there is nominimum number of records necessary and no particular level of diseaseintensity required. But it will also process, if present, the mostprevious office record of that out-patient (a status 1) in order toobtain the `baseline` condition of that patient just prior to the onsetof that illness. The number of records involved here also depends uponthe length of the continuous illness and after each record involved isdetected the subroutine binary.prg is also called.

Referring to FIG. 28, a print program entitled print1a.prg that reportsout physical data (signs and symptoms) in combination with other salientdata of both an identifying and clinical nature from officevisit-derived records created during one of the three main programsmentioned previously, in this case clinevol.prg. As such it representscontinuity of data flow through program sequencing.

Referring to FIG. 29, a continuation of the print program print1a.prg.Note how additional clinical data, if indicated, is also printed fromthe same office visit in combination with the signs and symptoms.

Referring to FIG. 30, another print program entitled print2a.prg thatcomplements print1a.prg by printing out medication activity data fromthe same office visits. In order to access the medicines involved inthat visit it calls a subroutine digout1.prg.

Referring to FIG. 31, a subroutine entitled digout1.prg called byprint2a.prg in order to locate the medicine activity record linked tothe office visit currently being processed for the purpose of organizingthe data and encoding it for printing it back in print2a.prg.

Referring to FIG. 32, a print program entitled print3.prg thatcomplements both print1a.prg and print2a.prg by reporting out anotherclinical aspect of each of those office visits originally processed byclinevol.prg, this time it is lab test results. It also calls asubroutine.

Referring to FIG. 33, a subroutine entitled digout2.prg called byprint3a.prg in order to access the lab test results from lab recordslinked to that office visit record currently being processed.

Referring to FIG. 34, an interactive query routine entitled Caseload.prgthat has a monitoring function. By counting on the system's mastermedical file it determines if there is a proper balance or distributionof out-patients on the database with a particular diagnosis amongst thedatabase doctors. Is there any doctor who carries an inordinate amountof patients with a particular condition, since the database consists ofnon-specialist, primary care doctors?

Referring to FIG. 35, a subroutine entitled print4.prg called byCaseload.prg for the purpose of computing and formatting the data intopercentage terms and displaying it to the screen.

Referring to FIG. 36, another interactive query routine entitledmeditoxi.prg that serves another type of monitoring function. For anygiven medication and database doctor, who are the patients under thecare of that doctor and on that medication, if any, who are in an actualor impending situation of medication induced toxicity. As such itdisplays lab test results in chronological order that are known to besensitive to the adverse effects of the medication inquired into alongwith the amounts that patient is taking.

Referring to FIG. 37, another interactive query routine entitledHeartmed.prg that also produces summary type and narrowly focusedclinical data. It identifies office visit records of out-patients whohave at least one diagnosis indicating chronic Heart disease of somenature and who have been documented at that visit of being in a clinicalstatus of 3 (severe symptoms). Upon that, the program combines thephysical data and any medication data and displays it on the screen withother identifying data. In order to access the medication data, it callsa subroutine.

Referring to FIG. 38, a subroutine entitled Medget.prg that is called byHeartmed in order to search for and test the medication activity recordlinked to the office visit under processing for evidence of change data.It then organizes that data for passage back to Heartmed for display tothe screen along with the physical data.

Referring to FIG. 39, the top, main calling program entitledlabfirst.prg in the overall process that creates and loads records withlab test results. Note it is primarily involved with the entry ofinitial identifying data and then determining the invoice (or mostunique aspect of any record type) to be assigned to the record that willbe created. It then passes control to lower level programs that performother specific functions in the process.

Referring to FIG. 40, the main subroutine entitled labentry.prgcontrolling several functions including the actual creation and loadingof the test results along with their parameter data. It generates a menuthat enables the selection from which other lower level routines arecalled in order to access prior results from several different aspectsfor each current lab test result present for entry. From there controlis returned to labfirst.prg when finished.

Referring to FIG. 41, a subroutine entitled Findout1.prg that is enteredif the user had selected from a menu of options in the higher subroutinelabentry.prg to obtain either the first date abnormality for any labtest and the results or the last date of abnormality for that test andthe results. Control is then passed back to labentry.prg.

Referring to FIG. 42, a subroutine entitled findout2.prg that is enteredif the user had selected from a menu of options in the higher subroutinelabentry.prg to obtain either how consistent the results have been forthat lab test or the most recent result for that test. Control isreturned back to labentry.prg.

Referring to FIG. 43, the top, main calling program entitledDoctorpg.prg of another interactive query routine that generatesnarrowly focuse clinical data. In this case either a set of lab testresults from a particular office visit or individual results of any labtest from several different, prior aspects. In this routine that choiceis made and the name of the name of the patient whose data is to belooked is entered. It then calls a lower level subroutine.

Referring to FIG. 44, a main subroutine of the interactive query routinewhose main program is illustrated in FIG. 43. It is this subroutine thatis entered if the results of individual lab tests was selected inDoctorpg.prg, and form here the selection is made on what prior aspectsof that lab test should the results be expressed. The two lower routinescalled by selectpg.prg are not shown since they are identical to the twolowest subroutines of the labfirst.prg that creates and loads labrecords.

Referring to FIG. 45, the main, top calling program entitledaddencrc.prg that controls the process that creates and loads a newoffice visit record. The only data entered here is the patient ID numberand whether or not the main reason for that visit was a new problem.Otherwise all the other data is accessed and entered from lowersubroutines under its control.

Referring to FIG. 46, the subroutine addnewrc.prg called by addencrc.prgfor a first time office visit record creation and data entry. Onceentered it acts like addencrc.prg in controlling the processing of thelower subroutines.

Referring to FIG. 47, the main subroutine entitled part1.prg of theoffice visit data entry. It is here that the record is created and themain data is written to it. It includes the multiple steps involved inaccessing the full 6 digit codes of the chronic diagnoses, and the 6digit code for the condition code field which represents the main reasonfor that office visit. It also controls entry into the two lowersubroutines that load the physical data.

Referring to FIG. 48, a lower level subroutine entitled part2.prg calledby part1 in order to load up to two physical symptoms that may bepresent on the data entry form to the new office visit record.

Referring to FIG. 49, a lower level subroutine entitled part3.prg calledby part1 in order to load up to two physical signs that may be presenton the data entry form to the new office visit record.

Referring to FIG. 50, an illustration of the model data entry sourcedocument used for loading the office visit record created inaddencrc.prg. Note how it provides for two alternate methods forentering the physical data (signs and symptoms)

Referring to FIG. 51, a main program entitled Addmedrc.prg that createsand loads a master medical record once for each out-patient on thedatabase. The program uses two alternate methods for the entry of up tothree diagnosis for any out-patient. There is only one master medicalrecord for each out-patient on the database.

Referring to 52, a subroutine entitled checkrec.prg called byaddmedrc.prg that tests if the chronic diagnosis that were entered tothe master medical record created is properly sequenced in relation toeach other depending upon their relative positions in the chronicdiagnosis table.

Referring to FIG. 53, a model source document for use in the data entryprogram that creates and loads one master medical record for eachout-patient on the database. Note the presence of two alternate methodsfor entering the chronic diagnoses.

Referring to FIG. 54, a main program entitled Overdrawn.prg thatmonitors for the overuse of office visit based lab tests. It searchesfor results from lab tests drawn during office visits that were entirelyunremarkable and uneventful, and then combines those results with theirmost recent results along with other salient data from both theirrespective visits in order to determine why the later tests were drawn.In order to access the lab data it calls a subroutine.

Referring to FIG. 55, a subroutine entitled digoutod.prg called byoverdrawn.prg for accessing both lab results from the currentlyidentified office visit, and for each test present it accesses it's mostrecent result from any of that out-patient's prior lab records.

Referring to FIG. 56, the system's office visit file, encounte.dbf,loaded with sample data for processing by schedule1.prg in order todetect and justify any early and consecutively uneventful office visitby an out-patient.

Referring to FIG. 57, the remaining office visit records of the filedepicted in FIG. 56.

Referring to FIG. 58, the system intermediary file, notify.dbf, as theoutput from a run by schedu1l.prg while using the sample data of FIGS.56 and 57 as the basic unit of information. Note the anomalous type ofcondition code in record #1 and how it has no effect on processing sinceonly the setting in the new problem field is tested and not the actualnature of the 6 digit condition code itself.

Referring to FIG. 59, the system laboratory test file, abn₋₋ lab.dbf,sample loaded and as one of several related out-patient files for use inschedu1l.prg in the search for data justifying the early consecutivelyuneventful office visit of an out-patient.

Referring to FIG. 60, the remaining four system files that containrelated out-patient data for use in searching for clinical data inschedu1l.prg that can justify an early consecutively uneventful officevisit by an out-patient. They are er₋₋ room.dbf(A), surgfind.dbf(B),pt₋₋ hosp.dbf (C) and treatmen.dbf(D). All are loaded with sample data.

Referring to FIG. 61, a version of the office visit file for serving asbasic input to the program unsched1.prg.

Referring to FIG. 62, the remaining office records of the file namedencountu.dbf depicted in FIG. 61 and which is identical, except forname, as the office visit file encounte.dbf. (its last letter changed toidentify it as sample loaded for special use by a particular program)

Referring to FIG. 63, the system intermediary file, notify.dbf, nowrepresented as output from an unsched1.prg run. Note the presence of the`C` indicator written to the CODE field of a notify.dbf record ininstances of consecutive unscheduled office visits for the same patientthat the program unschedul.prg is designed to identify while the samefield is used for indicating an absolute justification in instances ofearly scheduled and consecutive office visits by the same outpatient,something which unschedl.prg is also capable of identifying anddocumenting.

Referring to FIG. 64, a version of the office visit file namedencountb.dbf that serves as basic input to astatusb.prg.

Referring to FIG. 65, the remaining office visit records of the filedepicted in FIG. 64.

Referring to FIG. 66, the system intermediary file now as output fromthe program astatusb.prg. Note the second character in the CATEGORYfield that indicates the name of the program.

Referring to FIG. 66A, a translation table for illustrating how, in thebinary.prg subroutine, the assignment is made of a single letter code toeach of 16 possible types or combinations of physicianaction orintervention occurred during an office visit, including the code fornone at all.

Referring to FIG. 67, schematic of computer program execution sequencesthat demonstrate continuity of data flow. Output to an intermediaryfile, notify.dbf, is then used as input to a print program in both theupper and lower diagram.

Referring to FIG. 68, the system medicine-activity record file,medicine.dbf, sample loaded for use with the program atatus3.prg.

Referring to FIG. 69, another sample loaded version of the office visitrecord file as the basic input to astatus3.prg. Note how the last letterof name has been changed in order to properly identify and access thisparticular version of the office visit file for use with astatus3.prg.

Referring to FIG. 70, remaining office visit records of the encount3.dbffile.

Referring to FIG. 71, the system intermediary file, notify.dbf, now asoutput from astatus3.prg. Note the relationship between record #1 and #5of notify.dbf and that of #8 and #30 in medicine.dbf of FIG. 68.

Referring to FIG. 72, the system's physical signs table, findings.dbf.For use in the physical data report of print1a.prg.

Referring to FIG. 73, another sample loaded version of the office visitfile, encounte.dbf for use as basic input for clinevol.prg.

Referring to FIG. 74, remaining office visit records of the encounte.dbffile.

Referring to FIG. 75, the system's physical symptoms table, cc₋₋list.dbf, for use in the physical data report of print1a.prg.

Referring to FIG. 76, the system's chronic diagnosis table,chrmed1i.dbf, for use in print1a.prg.

Referring to FIG. 77, another example of the system intermediary file,notify.dbf, generated as output from clinevol.prg and now serves asbasic input to print1a.prg, which is based upon a chronic diagnosis asthe primary reason for an office visit.

Referring to FIG. 78, an out-patient office based physical data report.Note the indication of whether or not resolution of the out-patientillness has or hasn't occured. Note that two physical data items of thesame type (signs or symptoms) present in the same office visit recordare separated by the "and" when both are printed out during thatout-patient's processing.

Referring to FIG. 79, an out-patient office based physical data reportwhich, like in FIG. 78, shows two visits by the same patient. Notehospitalization indicator while the clinical resolution indicator is setto positive because the next record in the office visit file is thatout-patient's and its clinical status is a 1 indicating a return of thepatient's clinical condition to normal or baseline and thereforetermination of the out-patient illness.

Referring to FIG. 80, another out-patient physical data report.

Referring to FIG. 81, another out-patient physical data report, thistime only one visit for an out-patient is involved. Note that itresulted in a hospitalization but at the next office visit, thatout-patient was found to be without continuing illness due to thepresence of a clinical status of 1 resulting in the `problem resolved`indicator as shown.

Referring to FIG. 82, another out-patient physical data report involvingtwo visits by the same patient.

Referring to FIG. 83, another out-patient physical data report.

Referring to FIG. 84, another out=patient physical data report, thistime involving 3 office visits.

Referring to FIG. 85, another out-patient physical data report, thistime involving 5 office visits by the same patient. Note that after thesecond record there has a temporary termination of the illness asindicated by the `problem resolved` message but that was apparently onlya brief remission followed by a re-occurrence of another period ofillness.

Referring to FIG. 86, another out-patient physical data report.

Referring to FIG. 87, another sample loaded version of the system mastermedical record file, medical.dbf, for use in the querying of lab data bythe program doctorpg.prg.

Referring to FIG. 88, continuation of the master medical file,medical.dbf. Note record #12 for use as the sample data that generatesthe display illustrated in a higher number figure.

Referring to FIG. 89, the continuation of medical.dbf records displayedin FIGS. 87 and 88.

Referring to FIG. 90, another sample loaded version of the system officevisit file for use in the querying of out-patient lab data. Note thesample data of record #19 for use in generating the display to be foundin a higher numbered figure.

Referring to FIG. 91, continuation of the office file records of FIG.90.

Referring to FIG. 92, a sample loaded version of the system laboratorytest file, abn₋₋ lab.dbf, for use in the querying of out-patient labdata. Note records numbered 8 and 25 for use in generating the displayto be found in a higher-numbered figure.

Referring to FIG. 93, continuation of the system laboratory test file ofFIG. 92.

Referring to FIG. 94, alternate displays of the lab data queryingroutine depending upon the user's choice. Subfigure A displays all thetest results ordered from the same office visit while subfigure Brepresents the results of an individual lab test from one of severalhistorical perspectives.

Referring to FIG. 95, another sample loaded version of the system mastermedical file, medical.dbf, for use in the querying routine namedmeditoxi.prg.

Referring to FIG. 96, continuation of the system master medical file ofFIG. 95.

Referring to FIG. 97, continuation of the system master medical filedisplayed in FIGS. 95 and 96.

Referring to FIG. 98, another sample loaded version of the systemlaboratory test file, abn₋₋ lab.dbf, for use in the querying routinemeditoxi.prg. Note records 11, 12, 13 and the `wbc` field for use in themeditoxi.prg screen display of a higher numbered figure.

Referring to FIG. 99, continuation of the system laboratory file, abn₋₋lab.dbf, from FIG. 98.

Referring to FIG. 100, subfigure A displays two separate sequentialsteps of meditoxi.prg. First is a listing of all out-patients who arecurrently taking the medication entered at the top of the routine andwho are under the care of the doctor whose name was also entered at thetop of the routine. Then after one of the names of the patients listedis entered, all the results of that test on file for that patient arelisted in chronological order. Subfigures B, C and D are displays fromthe querying routine named Heartmed.prg. They list the physical datadocumented and any medication activity enacted by a database doctor forthose out-patients selected on the basis of chronic cardiac disease andwho were very symptomatic(ill) during an office visit.

Referring to FIG. 101, a sample loaded version of the systemmedicine-activity file medicine.dbf, used in the heartmed.prg queryroutine.

Referring to FIG. 102, a sample loaded version of the laboratory testfile, abn₋₋ lab.dbf, for use in the report program, overdraw.prg, theoutput of which is illustrated in a higher numbered drawing.

Referring to FIG. 103, continuation of the laboratory test file of FIG.102.

Referring to FIG. 104, another sample loaded version of the systemoffice visit file, encounte.dbf, for use in the overdraw.prg reportprogram.

Referring to FIG. 105, continuation of the office visit file of FIG.104.

Referring to FIG. 106, an out-patient report generated by the programoverdraw.prg. It involves three office visits. Note how the most recentresult for any two tests ordered at the same office visit (and thereforedrawn at the same time) may have been ordered from different prioroffice visits and therefore found in different lab records of thatpatient.

Referring to FIG. 107, another out-patient report from the overdraw.prgprogram. This involves two office visits.

Referring to FIG. 108, another out-patient report from overdraw.prg.Note how the Sed Rate test result from the office visit of 01/13/87 thenappears on the right hand side as a most recent result of that testordered during the subsequent office visit of 02/17/87. Note that threevisits for that patient are involved.

Referring to FIG. 109, another out-patient report from the overdraw.prgprogram.

Referring to FIG. 110, another out-patient report from the overdraw.prgprogram. Note how, for the ekg results from the third office visit, themost recent ekg results are drawn from a different prior lab record thanthe other results for that patient.

Referring to FIG. 111, another out-patient report from the overdraw.prgprogram.

Referring to FIG. 112, another sample loaded version of the systemmaster medical file, medical.dbf, for use in the caseload.prg program.

Referring to FIG. 113, continuation of the system master medical file ofFIG. 112. Note the sample use of the 6 digit chronic diagnosis codeCP0026, iron deficeincy anemia, for use in the caseload program displaypresent in a higher numbered figure(drawing).

Referring to FIG. 114, continuation of the master medical file of FIG.112 and 113.

Referring to FIG. 115, output from the program caseload.prg. Note theout-patient breakdown into diagnostic categories for the doctor whosename was entered.

Referring to FIG. 116, diagrammatic outline of sequential computerprograms and progression of data flow. Office visit records are firstprocessed by any of 3 routines that identify office visits thatrepresent protracted out-patient illnesses and determine what thephysician observed and did. The data compiled into those records createdand written to as a result of the aforementioned processing are thenused for any of 3 print programs that report out clinical data fromthose original visits. The phrase `new clinical problems` indicates thatthe office visit(records) selected were on the basis of a new clinicalproblem(or an as yet uncharacterized complication of an establisheddiagnosis) as the primary reason for that patient's office visit.

Referring to FIG. 117, a version of the laboratory test file loaded withsample data for use in the lab test data report program, print3.prg.

Referring to FIG. 118, a sample loaded version of the systemintermediary file, notify.dbf, for use with the lab test report programprint3.prg. It is identical to that present in FIG. 141 but has lesstotal records since the print3.prg cutoff date is different from that ofprint1.prg and print2.prg.

Referring to FIG. 119, an out-patient lab test report by print3.prg.

Referring to FIG. 120, an out-patient lab test report by print3.prg.

Referring to FIG. 121, an out-patient lab test report by print3.prg.

Referring to FIG. 122, an out-patient lab test report by print3.prg.

Referring to FIG. 123, an out-patient lab test report by print3.prg.

Referring to FIG. 124, an out-patient lab test report by print3.prg.

Referring to FIG. 125, an out-patient lab test report by print3.prg.

Referring to FIG. 126, the system's inventory type medication tablelisting the generic names of the medicines available to the databasepatients, med₋₋ list.dbf.

Referring to FIG. 127, a sample loaded version of the transactional typemedicine-activity record file, medicine.dbf, for use in the execution ofprint2.prg.

Referring to FIG. 128, an out-patient medication change report byprint2.prg.

Referring to FIG. 129, an out-patient medication change report byprint2.prg.

Referring to FIG. 130, an out-patient medication change report byprint2.prg.

Referring to FIG. 131, an out-patient medication change report byprint2.prg.

Referring to FIG. 132, an out-patient medication change report byprint2.prg.

Referring to FIG. 133, an out-patient medication change report byprint2.prg.

Referring to FIG. 134, an out-patient medication change report byprint2.prg.

Referring to FIG. 135, a sample loaded version of the system mastermedical file, medical.dbf.

Referring to FIG. 136, a continuation of the master medical file of FIG.135.

Referring to FIG. 137, a continuation of the master medical file of FIG.136 and 135

Referring to FIG. 138, the physical complaints or symptoms table, cc₋₋list.dbf, for use in physical data report print1.prg.

Referring to FIG. 139, the physical findings or signs table,findings.dbf, for use in the physical data report print1.prg.

Referring to FIG. 140, the short term diagnosis table, er₋₋ list.dbf,for use in the newproblem report of print1.prg.

Referring to FIG. 141, by initial processing, an abbreviated segment ofthe intermediary file, notify.dbf, for use in print1.prg.

Referring to FIG. 142, the system intermediary file, notify.dbf, for usein and just prior to initial processing by print1.prg

Referring to FIG. 143, continuation of the intermediary file,notify.dbf, from FIG. 142 and as it exists just prior to initialprocessing by print1.prg.

Referring to FIG. 144, an out-patient physical data report byprint1.prg.

Referring to FIG. 145, an out-patient physical data report byprint1.prg.

Referring to FIG. 146, an out-patient physical data report by print1.prg

Referring to FIG. 147, an out-patient physical data report byprint1.prg.

Referring to FIG. 148, an out-patient physical data report byprint1.prg.

Referring to FIG. 149, an out-patient physical data report byprint1.prg.

Referring to FIG. 150, an out-patient physical data report byprint1.prg.

DPE DESCRIPTION OF PREFERRED EMBODIMENTS

Referring to FIG. 17, a main computer program entitled Schedul1.prg thatidentifies, compiles data and creates records for the storage ofinformation about potentially over-scheduled and unnecessary officevisits. If a number of specific criteria, to be enumerated, are found intwo successive office visits by the same out-patient, and that occuredtoo quickly, the program and its subroutine will search on a set ofrelated out-patient files, each storing different aspects of medicaldata, for any clinical data that either might or will justify the earlysecond office visit. It will access information for determining if therewas any valid reason for the second scheduled office visit if it turnsout to be as unremarkable as the first and has occured too early,therefore representing a waste of clinical time and resources in thatout-patient's care.

Initially, as indicated by step 0102, office visit records (see FIG. 4,encounte.dbf) are selected by diagnostic category and those set ofrecords then serve as the basic unit of information processing for thisroutine. Next, as in steps 0103 thru 0120, the program skips througheach office visit record until one of the MINIMUM CLINICAL ACTIVITY typeis identified. That is defined as being 1) a scheduled visit as opposedto an unscheduled one, 2) the clinical status of the out-patient is a 1indicating normal or baseline, with no new or unusually active problems,3) no medication ordered during that office visit, 4) no lab testsordered, 5) no specialty referrals made, and 6) the main or primaryreason for the office visit being one of the out-patient's chronic, longterm diagnosis as opposed to an acute short-term one. In short, anuneventful and unremarkable office visit. But if another just like thatfor that out-patient occurs next and it's too early for that diagnosticcategory then someone (?doctor) may be scheduling that out-patient toosoon, often and without any valid reason.

It is the purpose of this program to identify and resolve that.

Upon identifying a first record of the MCA type, and as illustrated,counters and indicators are set and a group of values from thatout-patient's record are temporarily stored. If the next record is fromthat same out-patient, it is then subjected to the same tests to see ifit is also of the same scheduled MCA type. If it is not the same patientor of the same type, counters and indicators are re-set, previous storedvalues are cleared and the program skips to the next record. If it is ascheduled visit for the same out-patient and it is determined to be ofthe MCA type, the program then computes the interval of time between thetwo successive visits and if the interval is equal to or greater thanthat prescribed for that out-patient's diagnostic category the samething as above happens and that second MCA record then becomes the firstfor that out-patient. However, if the time interval is less then apossible condition of resource over-usage exists and at step 0121,therefore, a subroutine named searchv.prg is called (see FIG. 19 and 20)to determine if that second, early MCA type visit for that out-patientis in any way justified on clinical grounds.

As FIG. 19 illustrates a set of related out-patient files, each storingdifferent aspects of clinical data, is searched for any interveningevent or activity between the two MCA visits that might or could justifythe early second one. As step 0301 illustrates, the search begins on thesystem's emergency room file (see er₋₋ room.dbf, FIG. 15) to find arecord with a date within that time interval. If found then that invoiceis saved as a low level or soft justification but an absolutejustification isn't made until two further criteria are met; a clinicalstatus that indicates a need for a follow-up soon with an office visitor even the suggestion of hospitalization during the ER visit and the ERrecord condition code field is identical to that of the second, earlyMCA office visit of that out-patient (i.e. the same reason and type ofdiagnosis for both visits). If absolute justification isn't found thesubroutine continues searching for another ER record for thatout-patient with an intervening date. If found that invoice overwritesthe first one and the two additional criteria are tested for, ifabsolute justification is ever found an indicator is set and the searchon that file ends. If a record with even an intervening date is neverfound then an invoice is not saved and if more than one record with anintervening date is found, the invoice from that out-patient's latestrecord is saved. Regardless of the outcome, the subroutine searches nexton the system's hospital record file for any data that might or couldjustify that out-patient's second, early MCA visit.

As step 0312 in FIG. 19 illustrates, processing on the hospital file isvery similar to that on the ER file. If a record with an interveningdate is found indicating a hospitalization the invoice is saved butabsolute justification is not established unless there is exact identitybetween the 6 digit discharge diagnosis code and the 6 digit conitioncode field of the second, early MCA type office visit record indicatingcontinuity and consistency of out-patient care. Once again, as with theER file processing, one of three possibilities will exist in regard toclinical justification; no intervening date at all and therefore noinvoice saved or even soft low level justification, an intervening datebut no absolute justification by testing and absolute justification withan indicator set for informing the main program of that when control isreturned there. And as before, if absolute justification is foundsearching on that file is terminated.

At that point, the system's treatment file is searched for anyintervening record dates for that out-patient to see whether or notthere is any clinical data present during any of those sessions toindicate a reason for the early, second MCA type office visit.

As step 0320 of FIG. 19 illustrates, and as before, if a treatment file(see FIG. 14, treatmen.dbf) record with an intervening date is foundbetween the two MCA office visits the invoice of that record is savedfor indicating at least low level justification. For absolutejustification a field in that record is tested for either a valueindicating a complication has occured or just a suggestion by thetherapist that the out-patient return to see the primary care doctorearlier than already scheduled due to some problem the therapist thinksexistent. As step 0325 illustrates, if that was the case then absoutejustification is established, the indicator is set (it is set no matterhow many times absolute justification is found) and the treatment filesearch on that out-patient ends. And as before, if just low level orsoft justification is found but exists in more than one record (i.e.intervening date) it is the invoice from that out-patient's last recordin that file that is saved.

As is seen by step 0329 in FIG. 19, the search is then continued on thelaboratory file in order to find any data there that could serve as abasis for that early, second MCA out-patient visit. As the next step0401 in FIG. 20 shows, a record is looked for with a date between thetwo MCA type visits (i.e. when the tests were taken) and if found aninvoice from that lab record is saved. Then each of the 14 lab testfields that store different lab test results are searched for anyabnormal results (normal results are disregarded since they can'tprovide a basis for absolute justification). If an abnormal result isfound it is then tested for an indicator that documents that abnormalvalue as either acute in onset or a significant change from a mostrecent result of that test for that out-patient. If either of thoseindicators are found associated with an abnormal result for a lab testfrom a record for that out-patient with a date between those two MCAtype visits, then absolute justification for that second, early MCAvisit is established since that is a pretty good reason why a physicianwould want to see a patient earlier than scheduled. (see abn₋₋ lab.dbf,FIG. 7) And as before, the search on that file ends.

And as again, it is the invoice from the first record that providesabsolute justification, if such is found, that is saved and passed tothe main program and if just soft or low level justification is found,it is the invoice from the last record with an intervening date that issaved.

As can be seen by step 0409, FIG. 20, program control is then returnedback to step 0122 of FIG. 17 upon terminating the laboratory filesearch.

Upon return to the main program (see FIG. 17) at step 0122, a new recordin the system's intermediary file (see FIG. 5, notify.dbf) is createdand written to with salient out-patient identifying data and if presentboth or any type of justifying data found during the searches in thesubroutine searchv.prg. Now, any additional justifying data is sought inthe main program by searching on the surgical history file (seesurgfind.dbf, FIG. 13). Unlike a simple hospitalization occuring betweenthe two dates of two MCA's not being an automatic hard or absolutejustification for the second, early MCA, any surgery occuring within thetwo dates is of course automatically presumed to be with both invoicesaved and the indicator set. However, even if there wasn't anyintervening surgery between the two MCA dates, if that out-patient hashad surgery in the recent past, depending upon its nature and data inthe office visit itself as well as when the surgery occured, that pastsurgery even though occuring as much as months before may provide atleast partial or soft justification for the early second MCA visit (seesteps 0204 0205 0206). As is illustrated, the more extensive or criticalthe surgery, i.e. the higher the category it occupies in the surgicalinventory table (see FIG. 13, surglist.dbf), then a greater amount oftime is allowed between that event and the first MCA type visit for thatout-patient for it to justify the second, early MCA type visit. Inaddition and as illustrated in step 0209 of FIG. 18, for a category Csurgery an additional criteria must be met; in instances such as herniasurgery there must be an identity between the clinical group indicatorfor that kind of surgery (i.e. GI track) and that present in the 6 digitcondition code reflecting the main or primary reason for the second,early MCA visit.

Upon terminating the search on the system's surgical history file, theeffort to find justifying data to support that out-patient'ssecond-in-a-row unremarkable and uneventful office visit in whichnothing new or important was found or done and that also occured tooearly, no more searches are conducted on that out-patient in regard tothose two MCA's.

The newly created intermediary file record will now contain out-patientand the second MCA type visit identifying data that includes; patientI.D. No., Date, diagnostic category, name of the data processing routineby code, doctor, condition code and of course any and all invoices frompotentially justifying records as well as a code for indicating ifabsolute justification was found. In effect, a compiled story on whatwas found, when and for whom and by whom.

As seen by step 0217 of FIG. 18, after the above processing the programthen resets the second MCA type office visit as the first, resets thecounter and then skips to the next office visit to test for the samepatient, same MCA type or new out-patient, whatever the case may be anduntil end of office visit file.

Referring to FIG. 21 and 22, a main computer program that, likeschedul1.prg, also identifies potential instances of clinical resourceoverusage by office visits and compiles said data into new records. Butthis program detects overuse by the patient too and not just presumabelythe physician as in schedul1.prg since the kind of office visit thattriggers processing is the unscheduled one even though it may includethe MCA type one as well. As such it detects two types of problems, allconsecutive unscheduled visits after a first one for that out-patient(?patient's fault) and an early scheduled MCA type following anunscheduled MCA type visit (physician's fault?)

As is illustrated in step 0501, initially office visit records areselected by diagnostic category for group specific analysis (as inschedul1.prg). As seen by step 0502, further program specific processingisn't triggered until and if an office visit record indicating anunscheduled type is identified. When that happens that record is thentested to see if it is the first of that type for that out-patient. Ifit isn't but instead a second or more consecutive unscheduled visit forthat out-patient, a new record in the system's intermediary file is thencreated for each of those consecutive unscheduled visits beyond thefirst one and pertinent identifying data is naturally written to them.Such data includes patient i.d. no., clinical status during officevisit, what consecutive number, the program name, type of visit, date,diagnostic category of patient, invoice of office visit, etc. Then as isillustrated in step 0517, even in cases where it is the firstunscheduled office visit and data for that record won't be collected,tests are done to it to see if it is of the MCA type in order to preparefor the possibility that the next office visit record may also be of theMCA type for that out-patient but of the scheduled type (which wouldmake it the physician's fault if it is also too early). And if that isthe case then, as in step 0512, the time interval between theunscheduled and the scheduled MCA for that out-patient is computed andcompared against that time interval as prescribed for that out-patient'sdiagnostic category. If found to be less than the prescribed interval oftime then, as in the previous routine schedul1.prg, the subroutinesearchv.prg is called for the same reason; (see step 0514) to search onrelated system files each linked to that out-patient by common fieldsand which store different aspects of medical data for the purpose offinding any intervening event or activity that could justify the second,early scheduled MCA type visit of that out-patient and thereby provide areason for what otherwise appears to be a waste of clinical resources.Then, and as in schedul1.prg. a new record is created and pertinentout-patient and office visit identifying data are written to it as wellas the source of any potentially justifying data as well, whether or notabsolute justification was found. However, and independent of whether ornot searchv.prg is called and since that just-processed record for thatout-patient was of the scheduled type, the `chain` is broken in thisprogram since it is centered around the unscheduled office visit andtherefore counters are reset to zero, stored values are cleared and thenthe program will skip to the next office visit record until anotherunscheduled type of that or another out-patient is again encountered orend of file is reached.

In this program and unlike schedul1.prg at the end of office visit filethere are, or might be, two type of new records created (i.e. holdingdifferent data) in the system's intermediary file (see FIG. 5,notify.dbf). One type that identifies all consecutive unscheduled officevisits for out-patients and tallys the number of consecutive ones ineach new corresponding intermediary file record (notify.dbf) created asa result. The other type is, except for name of program, identical indata types and content as the one created in schedul1.prg for eachearly, second MCA type scheduled successive visit for any out-patientthat is found.

Referring to FIG. 22, a subroutine entitled surgfind.prg that is calledby this main program, unschedul.prg, for searching on the out-patientsurgical history file for any jusitfying clinical data. In source codeand function it is identical to that block of code for doing the samething in schedul1.prg but in this program it was made a separatesubprogram or subroutine due to lack of `byte` space in the programunschedul.prg.

Referring to FIG. 23, a main computer program entitled AstatusB.prg thatdetects and isolates a group of office visit records that represent aprotracted out-patient illness of moderate severity (not worse thanclinical status 2) and then compiles data to new records, eachindicating what was found and done during each of the visits during saidprotracted illness. In order to trigger program processing a minimumnumber of `abnormal` records in succession must be found for any oneout-patient. And the records are only of two types of clinical statuses;one is a status 2 indicating moderate symptoms and the only other may bea 4 indicating an improvement in symptoms, and lessening of severity.

Initially, as is seen by step 0701, office visit records are selected bydiagnostic category for group specific analysis. As is illustrated insteps 0705-0712, at least 3 consecutive office visit records for anyout-patient must be found before any further program specific processingoccurs. Also, all of the contiguous out-patient records must have thesame chronic diagnosis in the condition code field as the primary reasonfor the office visit. Once that minimum number of records in successionoccurs, another subroutine called binary.prg is called that will nowprocess as a group each of those `abnormal` out-patient records thatoccured in succession. As will be discussed, that subroutine willdetermine and resolve exactly what was done by the physician during eachof those visits involved in that protracted episode of moderate illness.After that minimun of 3 records are processed together, control goesback to the main program AstatusB.prg and if any further successive orconsecutive records for that out-patient are found of the same statustype, 2 or 4, each record at that point is sent individually into thebinary.prg subroutine for separate processing. Once a non- 2 or non-4status is encountered or another out-patient record is found, theprogram counter is reset to zero and another minimum of three recordsconsisting only of those 2 status types must be found before programprocessing can begin again. At the time the end of office visit file isreached and for each of any office visit record involved in programspecific processing of any protracted out-patient illness, acorresponding new record in the system's intermediary file, notify.dbf,is created storing patient and office visit identifying data and anencoded compilation of what was done, including medication, lab tests,referrals, etc.

Referring to FIG. 24, the subroutine binary.prg firsts positions to theoffice visit record to be processed in the main program. It then tests apassed indicator to test for which of three possible main programs hascalled it, AstatusB being only one, and sets aside an appropriate codefor designating that. As is illustrated in step 0802, it then savespatient and office visit identifying data, and as an independent checkit also sets another indicator depending upon the nature of the officevisit condition code (i.e. primary reason for the office visit): whetherit is a new acute problem or a chronic, established one. At this pointand as illustrated in step 0803, it determines which or how many of the4 possible actions or types of physician intervention took place duringeach of said office visits involved in said protracted illness for anyout-patient, which may include new medication, change in existingmedication, laboratory tests and speciality referrals. The determinationis made possible since each of the 4 actions occupy fixed positionswithin a four digit binary number and therefore each has a designatedplace value corresponding to an assigned field in the office visitrecord. Therefore, any combination of those 4 physician interventionactivities will result in a distinct sum ranging from 0 thru 15 (16possibilities) depending upon which, if any, of the 4 possibilities weredone during any office visit. Each of the 16 possible numbersrepresenting what, if anything, was done are then assigned a singleletter as code ranging from A(0)-0(15), During the subroutineprocessing, binary.prg determines which ones, if any, of the logicalfields corresponding to the 4 actions are turned on or set to true(i.e..T.), it then computes the sum and then selects the correspondingsingle letter code for indicating accumulatively what, if anything, wasdone during that office visit. In addition to that subroutine processingof a given office visit record involved in the above said type ofprotracted illness processing, in instances where a referral was made,step 0811, or an injection was given, step 0804, further processingoccurs to access for the purpose of tracking, the invoice from thatspecialty record and in the case of medicine injections during an officevisit, the appropriate record in the system's medicine file forindicating the precise route of injection given to that out-patient,i.e. IM or IV. Then a new record in the system's intermediary file iscreated corresponding to that particular office visit record justprocessed and all of the above mentioned data identifying the patient,office visit, primary reason for office visit, actions by the physician,dates, etc. are written as compiled data to fixed positions in that newrecord (notify.dbf). Control is then passed back to any of threepossible main calling programs, which in the one under discussion isAstatusB.prg. (the other two discussed later)

Referring to FIGS. 25 and 26, a main computer program entitledAstatus3.prg that, similar to astatusB.prg, processes a continousuninterrupted sequence of office visit records of various length thatconstitute a protracted out-patient illness. However, unlikeastatusb.prg the protracted episodes here are of more severity and mayinvolve hospitalization. Also, and unlike Astatusb.prg, Astatus3prg doesnot require a minimum number of office visit record status types for agiven out-patient to be present contiguously. Instead, its processing istriggered whenever a status 3 office visit record is encountered whichindicates a level of severity greater than any involved in astatusb.prgprocessing and in terms of nature or degree of illness is consideredpre-hospitalization, which if occurs during any office visit would thenmake that visit a status 5. After the initiating status 3 office visitrecord, the program then processes all of any antecedent and thensubsequent or succeeding contiguous non-status 1 records for thatout-patient. Following the identification of said record types asdefined by their clinical status indicating severity of illness (1 beingnormal or baseline), the subroutine binary.prg is called to make thesame determinations and access the same data and write the same kind ofcompiled data to a newly created record in the system's intermediaryfile as occured during Astatusb.prg, the only difference being, sincebinary.prg is being called by a different main calling program, adifferent letter code is placed in the newly created record forindicating that.

The most critical aspect of processing in this program is the constantdetermination of the proper direction for record skipping and continualrepositioning to the appropriate record during processing, and how thatcontrol is maintained. That is necessary because as is seen in step0903, processing only begins when a status 3 record is encountered.Therefore, the program must be continuously `informed` as to which sideof the initiating status 3 record the record pointer is on in order to`know` whether or not to move back or to skip forward to examine anynext record for that out-patient. As can be seen in the figure, anysubsequent direction of the record pointer is always determined byconstant reference to a program flag which is always set based upon thelast direction in which it skipped and the value of the status field ofthe current office visit record under processing.

As is illustrated in step 0903, processing is first triggered when astatus 3 record is identified. At that point the subroutine binary prgis called and except for writing a program specific indicator into anewly created record of the system's intermediary file, processingidentical to that described during AstatusB.prg processing also occursin binary.prg during this main program processing. As seen in step 0911and assuming first time thru for this out-patient, the program flagcontrolling movement of the record pointer (i.e. record skipping) is setto `false`. Therefore, after processing through the subroutine, therecord pointer moves back to test for and if necessary subroutineprocess any non-status 1 record for that out-patient which is prior andcontiguous to the status 3 identified and processed just before. For anyfound, the subroutine binary.prg is again called for each one with therecord pointer continuing to move back until either a status 1 recordfor that out-patient is identified or another out-patient's office visitrecord is encountered or of course beginning of file (see steps 0912thru 0923). Beginning in step 0924, the program provides for that bythen resetting a flag for forward skipping and repositioning the recordpointer to one office visit record beyond the initiating or triggeringstatus 3 for that out-patient. In this way all subsequent (later) andcontiguous non-status 1 office visit records for that out-patient willalso be processed in the identical way to all prior (earlier) contiguousoffice visit records for that out patient. Beginning at step 0924 thesubsequent processing simply ensures that all subsequent status 3records for that out-patient are processed through the subroutinebinary.prg from a different point or block of source code in the mainprogram from that for the status 2,4 and 5's, while maintaining theproper setting for the flag controlling direction of record skippingdepending upon current setting and the value of the office visit recordstatus.

As an example and to assist in following the logic, assume ahypothetical out-patient has two current office visit records on file, astatus 1 preceding a status 3. The program will skip over the first butbegins processing when it encounters that out-patient's status 3 record.After returning from the binary.prg subroutine and with the flag havingbeen set initially to false, the record pointer is skipped back onerecord by the program. However, since it is a status 1 record, eventhough the same out-patient, that record won't be included in theprocessing. At that point and in order to check for later records forthat out-patient (after the initiating status 3 record) the flag is setto .T. and the record pointer is moved by the program (i.e. records areskipped) to one record beyond the initiating status 3. But since thatrecord is from another out-patient, current out-patient processing isterminated and the program flag is reset back to .F. or false inpreparation for eventually encountering a status 3 record in anotherout-patient. It is important to note that once a status 3 record isprocessed, any antecedent non-status 1 record(s) for that out-patientare always processed before any non-status 1 records for thatout-patient that are after (later) the initiating status 3 record ofthat out-patient. Conversely, and central to this program, if thereisn't any status 3 records on file for any out-patient at the time theprogram is run, none of that patient's non-status 1 records will beprocessed either; that out-patient will not be included in theprocessing.

At the end of the program (after the last record in the office visitfile) the system intermediary file (notify.dbf) will contain newnotify.dbf records containing compiled data that identifies thatout-patient and office visit, as with the AstatusB.prg program, for thepurpose of tracking and both what the physician found and what was doneduring each office visit involved in processing. And, as withAstatusB.prg, for each office visit record included in processing, onecorresponding notify.dbf record is created. And the only difference asfar as data is concerned is the single letter code written to indicatethe name of the main calling program, in this case Astatus3.prg.

Referring to FIG. 27, a main computer program entitled Clinevol.prgthat, like AstatusB and Astatus3.prg, identifies, isolates, determinesand compiles data from a cluster or groups of out-patient records thatrepresent a protracted out-patient illness of varying severity andduration. However, and like each of the prior two main programs, thedegree of severity or threshold necessary for triggering processing isdifferent, as well as the office visit statuses necessary to initiatethe processing and for being included in it.

Processing in this program is initiated by any first non-status 1record, regardless of type. Once that identity is made, the program willskip back to include any prior status 1 for that out-patient. That isfor the purpose of establishing a baseline, for reference, because it isapparent that the status 1 or `normal medical condition` office visitwas the last time that out-patient was seen before the onset of thecurrent illness. The program will then continue forward to processthrough binary.prg all further, later non-status 1 records for thatout-patient that occur consecutively until a status 1 record is found ora record of another out-patient is encountered or end of file.

Although its criteria for triggering processing is less `selective` thaneither AstatusB and Astatus3.prg, it provide a more natural and completeview of the evolution and management of an out-patient illness in anuninterrupted way.

As seen in step 1102 and as in the two prior programs, out-patientrecords are pre-selected by diagnostic category to enable group specificanalysis. As was mentioned above and as illustrated in steps 1104 thru1109, any first non-status 1 record will initiate processing. Once thattype of record is encountered and before binary.prg is called, theprogram moves back one record to check if it is a status 1 for the sameout-patient. If that is so then that record is sent into the subroutinebinary.prg first for determining, collecting and compiling what may beimportant baseline pre-illness data for reference since it just precedesthe record indicating onset of that out-patient's illness. Until step1120, the general processing flow is the same as in AstatusB andAstatus3 programs; for each office visit record included in theprocessing, a new intermediary file record is created, what was foundand determined during that visit by the binary.prg subroutine is savedand encoded and then after returning to the main calling program iswritten into the newly created record including patient and office visitidentifying data, However, there is an additional step performed by thisprogram, clinevol.prg,. As is seen in the steps 1120-1123, testing isdone to determine if a final resolution of that illness has occured atleast by the time the program is run. And as is illustrated, that isdone by determining the reason why that out-patient's record processingwas terminated, i.e. was it due to the presence of a status 1 record forthat out-patient indicating return to normal or baseline and thereforeend of illness or due to encountering the record of another out-patient,or end of file.

As in Astatus3 and AstatusB, for each office visit record included inprocessing, a corresponding new intermediary file record is createdthrough the binary.prg subroutine. However the difference inclinical.prg, and aside from the coded letter indicating the programname as part of the new compiled data written to each new record, thismain program, clinevol.prg, also writes to the last new record a letter,or leaves a space, for indicating whether or not clinical resolution ofthat out-patient's illness has occured.

Referring to FIGS. 28 and 29, a computer program (and without anassociated sub routine) entitled print1a.prg for printing out physicaldata (signs and symptoms) from office visits grouped by out-patientdiagnostic category. Its primary data source or basic unit ofinformation is the system intermediary file, notify.dbf. As such,records for use in this program were created and written to inpreviously discussed main programs, in this case clinevol.prg. And thecriteria used for selecting said intermediary file records are the samehere as they were in the previous main program for the selection ofoffice visit records. Therefore, print1a.prg is a sequential program orfollow-on routine that demonstrates the system's potential for unlimitedkinds of continuity in data flow and flexibility of data usage.

As is illustrated in steps 1201-1204, the program also selects by acontrol date and then an inter-file relationship is established thatwill link by out-patient the system's master medical file (medical.dbf)in a most likely one to many relationship with the system intermediaryfile, used in this main program as once again the basic unit ofinformation processing. In this way and prior to the detail lineprinting of clinica data, pertinent back-ground and identifying data foreach out-patient involved in processing is printed once per page asheading. Then, and since all the office visit derived records of thesystem's intermediary file, notify.dbf, that are pre-selected forprocessing in this main program contain only a Chronic, establisheddiagnosis as the 6 digit condition code or the primary reason for theoffice visit, it is the system's Chronic Diagnosis Table, Chrmedli.dbf,that is searched on and accessed for obtaining the literal, medical,text of that diagnosis corresponding to that 6 digit code. Then it issaved for later printing with other office visit data. Then a check ismade, step 1207, to see if the condition code, a chronic diagnosis inthis program, or any of the two other possible chronic diagnoses forthat out-patient, is of a blood pressure related and sensitiveclinico-pathological group (heart, neurology, etc.). If it is, theoriginal office visit record corresponding to the current notify.dbfrecord being processed is searched for and the blood pressure recordedat that time is accessed and temporarily saved. In step 1210, anyphysical data present in the notify.dbf records are then used to accessfrom their respective tables the corresponding literal, medical, textfor later printing of both symptoms and signs documented at the originaloffice visit and was later written during program processing to thenotify.dbf records from the office visit records.

The first detail line for printing clinical data from that office visitderived record in notify.dbf is then printed with pertinent identifyingdata only.

After step 1211, the program then determines which of the abovepotential data (i.e. signs and symptoms in encoded form) were actuallypresent in said office visit derived notify.dbf records, and thereforewhat further detail lines for that office visit are to be printed.

If blood pressure data is present, that is printed first. If physicalsymptoms data was documented during the original office visit that isprinted on the next line, and if both fields were devoid of data due tothe absence of any documentation during that original office visit thena `no symptoms are present` message is printed instead. The same processapplies to the physical signs data for the next line. The next step,1305, is for testing and then indicating if a hospitalization occuredduring that original office visit, as indicated by the status field datathat was written to the office visit derived notify.dbf record. The nextstep determines if, in the case of a last record processed for thatout-patient by the original clinevol.prg and pre-selected in this mainprogram for reporting out on, that protracted illness has ended or infact resolved by the time this program runs. If it is a last notify.dbfrecord for that out-patient then one of three possibilities exist; thenext record on file for that patient is a status 1 indicating a `cure`of that protracted illness, the next record on file is that belonging toanother out-patient and therefore the illness of the prior out-patientremains unresolved or it is end of file and unresolved. Whatever thecause, a brief message is printed on the last line of data from the lastintermediary file (notify.dbf) record for that out-patient.

Then the out-patient ID No. in the next record is tested and if it isstill the same, a single dotted line is printed to separate the clinicaldata from two office visits by the same out-patient. If it is adifferent out-patient then the program skips to the next page, printsthis out-patient's pertinent identifying data and repeats the process ofsearching, accessing, resolving and printing of any signs, symptoms andother clinical data for that out-patient.

Note that this program's `acute problem` counterpart or companion,print1.prg, (see FIG. 1) is virtually identical in source code exceptthat the condition code from the office visit derived records ofnotify.dbf reflects an acute, short-term diagnosis as the primary reasonfor the visit in that group of records and which in fact werepre-selected on that basis also (as opposed to a chronic, long termestablished diagnosis in this main program, print1a.prg) and thereforeit is the short term diagnosis table, er₋₋ list.dbf, that is searched onby the 6 digit code from the condition code field in order to eventuallybe able to print out, as in this program, the primary reason for thoseoffice visits in conjunction with other clinical data. For Print1.prg,see source code listings in the attached appendix.

Referring to FIG. 30, a main computer program entitled Print2a.prg thatprocesses and reports out any medication change activity during chronicproblem office visits by use of the same office visit derived recordsfrom the system intermediary file (notify.dbf) that was used inPrint1a.prg, those created and compiled from a run by clinevol.prg (seeFIG. 27). As another sequential, follow-on type program since it alsouses records built from a previous program. It complements print1a byreporting on a related but separate clinical aspect, in this casemedication, of those same out-patient primary care office visits.

As in print1a.prg each printed page represents data from a singleout-patient and may contain data from separate office visits with eachseparated by a single broken line. And again as in print1a, at step1403, a one-to-many relationship is established between the out-patientmaster medical file (medical.dbf) and the system intermediary file(notify.dbf) for accessing and then printing out out-patient backgrounddata as heading once per page. Data for passage to and resolution of inthis program's subroutine (digout1.prg) is saved and then the conditioncode from the notify.dbf record is used to search upon and access fromthe chronic diagnosis table its corresponding medical text for use inprinting.

At this point the subroutine is called (see FIG. 31, digout1.prg) fordetermining what medicines and how much were changed, and then accessingfor printing back in the main program with other data from that primarycare office visit.

Upon return from the subroutine a test is made to determine if in factany medication changes occured during that office visit. If none did, amessage identifying the office visit and indicating that is printed. Inaddition, if a medication record from that office visit can't be founddespite that activity being indicated during the above test, or it isfound but no changes are indicated in that medicine record then a dataerror message is printed. If a medication change code in that notify.dbfrecord is present, i.e. one of several possible single letters thatindicate that at least a medication change occured during that officevisit, and medication-change data is found in the related, linkedmedicine record of that out-patient, the data is accessed, placed invariables and then processed from those variables for detail lineprinting (see step 1414). Since there is the possibility of up to 3medication changes during any office visit, the group of variablespassed back to the main program are then tested for and accessed threetimes at three fixed positions corresponding to each of the 3 possiblemedication names that may be present and if so then their accompanyingamounts changed from and to expressed either in milligrams/day ortablets/day. Just prior to printing up to three possible detail linescorresponding to each medication change, and as in print1a, identifyingdata for that office visit is printed.

As in print1a.prg the program here checks the next record after printingto see if it's the same out-patient.

If it is then a broken line separating that office visit and its datafrom the next for that out-patient is printed and the above process isrepeated. If it's a different out-patient then the program skips to thenext page, prints program title, background data for that newout-patient and then repeats the above process until the end of theintermediary file, notify.dbf.

Note that this program's `acute problem` counterpart, print2.prg (seeFIG. 1) is virtually identical except that the main or primary reasonfor each office visit is an acute, short-term diagnosis and thereforethe 6 digit condition code representing that is used to search on theacute, short-term diagnosis table (er₋₋ list.dbf).

Referring to FIG. 31, a subroutine entitled Digout1.prg., mentioned inthe previous main program discussion since it is called by print2a.prg.Its purpose is to test for the presence of one of several single letterindicators that mean at least that a mediction change had been orderedby the physician during any office visit. It then locates theappropriate medicine record for the out-patient storing those changes,accesses them and temporarily saves that data for resolution in the mainprogram prior to printing.

The routine begins by testing the single letter code in the categoryfield of the office visit derived notify.dbf record of that out-patient.That single, coded, letter indicates which, if any, of four possibleactions the physician took during an office visit (see page 8 forexplanation). The single letter code from the category is tested foridentity against 8 single letters indicating at least the existence of amedication change. If a match is not made then that single letter fromthat out-patient's record is not one of the eight and control is passedback to the main program, print2a.prg, and a `not done` message isprinted for that office visit beneath its identifying data. If one ofthe 8 is present but the corresponding medicine record (see FIG. 9,medicine.dbf) isn't found a data error message is printed.

If that office visit derived record has one of those 8 lettersindicating a medication change and the corresponding medicine record isfound, each of the 3 medication fields are in turn tested for theindication of change activity, as opposed to an addition, deletion,etc., As in step 1506, for each field in which a change indicator isfound the 5 digit medication code and the amount that out-patient is nowon (amount changed to) is copied and saved.

The subroutine now will find the most recent medicine record for thatout-patient that stores each of up to three medicines that may have beenchanged. If there were 3 medication changes, the most recent amounts foreach of the three may be in three separate records for that out-patient.

The way that is done is by first positioning to that out-patient's firstmedicine record on file. That is done by first searching on a linkagefile (see firstmed.dbf) that stores the invoice for each out-patient'sfirst medicine record, accessing that invoice and then turning to themedicine file and using that invoice to position to the first record forthat out-patient. Then, for each of 3 possible medications that mighthave been changed, the corresponding 5 digit code previously saved istested against each of the three fields in each of that out-patient'ssubsequent medicine records on file up to but not including the currentor last record on file. For any of the three possible changes present,each time a match is found in one of the fields in any of the earliermedicine records for that out-patient and the associated indicator meanseither an add or a change, the corresponding amount is written to avariable. And each time another match against that same 5 digit code isfound then that amount will over-write the previous amount for thatmedication, in that way ensuring that the most recent amount for thatout-patient will be obtained. That amount is then stored with thecurrent amount, which is present in the last, latest medicine record forthat out-patient. Lastly, the 5 digit code is then used to access thefull generic name of that medication by searching on the system'smedicine inventory table, (see med₋₋ list.dbf). That is then also storedto the same variable holding both medication amounts; changed to andfrom.

The above process is repeated for each medication change found in themost recent medicine record in the medicine.dbf file for thatout-patient. Back in the main program, print2a, the variables passedfrom the subroutine are stepped through and the medication name and bothamounts are individually accessed and then formatted for printing in thedetail lines following the office visit identifying data.

Referring to FIG. 32, a main computer program entitled print3a.prg thatcomplements the previous two main programs, print1a and print2a, byreporting on another separate but related clinical aspect of the sameout-patient office visits; laboratory test results.

At step 1602 and as in the previous programs, records are pre-selectedfrom the system intermediary file notify.dbf by control date (cut-offdate) and the presence of a chronic diagnosis in the condition codefield of the office visit derived records indicating that as the primaryreason for the visit. However, unlike the previous two and due to thesize of this program there isn't any pertinent background data printedonce per page for each out-patient and therefore the linkage between thesystem master medical file and the office visit derived record file(notify.dbf) is not established in this program.

As is seen in step 1604, office visit identifying data written to thecurrent intermediary file office visit derived record (notify.dbf) isaccessed and saved while the chronic diagnosis table is searched on thecondition code to access the literal text corresponding to the 6 digitcode in the condition code field. The subroutine digout2.prg is called(to be discussed later) to determine if any lab work was done duringthat office visit and if so, search the system lab file on the officevisit invoice (lab records have dual invoices) for that relatedout-patient lab record storing test results ordered during that visit.That accessed data is then store to variables at discrete positionsspecific for both the numeric results and the historical, parameter dataassociated with each test for that out-patient that was done. After asearch is made upon all the 14 lab test fields for the presence of data(fields are blank for tests not done) and all that are present areaccessed and saved, passage back to the main program, print3a, occurs.

The rest of the main program basically involves determining which if anyof the 14 tests were done by stepping through to fixed points in each ofthe variables passed back from the subroutine and that hold separateaspects of that test result. Each test result occupies a fixed positionin each of the passed variables that correspond to its relative fieldposition in the lab record. After access, the test results are formattedand printed, each test result constituting a detail line.

As is seen in step 1618, upon return to print3a a test is done todetermine if in fact any test result data was present and thereforepassed back. If not, and as will be seen, it is either due to theabsence of any ordering of the tests by the physician during that officevisit or although tests were ordered and an indicator set during dataentry as a result, no record is found during program processing, i.e. adata error. Depending upon what happens, flags are set in digout2.prgand based upon that indication the appropriate message is printed inprint3a.prg, see steps 1619-1622.

When lab test data is passed back from digout2.prg to print3a.prg, thevariable dedicated to storing the names of the lab tests(i.e.hct,wbc,bld sugar, etc) are tested first. Each of the 14 arealloted equal space within that `dedicated` variable and the mainprogram steps through it at fixed positions 14 times testing for thepresence of data. Whenever a name is found, that indicates that theother aspects of that test result are present in the other variablesdedicated to those other aspects of that lab test result such as thequantitative abnormal result, parameter data like consistency ofresults, chronicity of abnormality comparison to most recent result andin cases of normal result the date of results. These are accessed in thesame way as the test name; by stepping through to fixed positions ineach of the dedicated variables depending upon the relative field numberof that particular test.

Immediately upon determining the first instance of a test name presentin that variable, print3a will print that office visit's identifyingdata and lab record identifying data (i.e. lab invoice and test date).Then as each test result is found the separate data items as otheraspects of the test result are also accessed, formatted and printed.After all 14 positions in the `name` variable passed from thedigout2.prg subroutine are tested for within that iterative loop processand each lab test result present is printed as a separate detail line,the next intermediary file record is skipped to and, as in previousprograms, if it is the same out-patient, a single broken line is printedwhile if the next record is another out patient then a double brokenline is printed and the program skips to the next page. In either caseand as before, the process continues until the end of the intermediaryfile is reached.

Note that this main program's counterpart, print3, is virtuallyidentical in design (structure and source code) except that, and as withthe previous two main programs, office visit derived records thatcontain a short term, acute diagnosis in their 6 digit condition codefield as the primary reason for the office visit are pre-selected forprocessing instead of, as in print3a, a chronic, long term one.

Referring to FIG. 33, the subroutine entitled digout2.prg called byprint3a.prg for the purpose of accessing from the system's laboratoryrecord file any outpatient test results that were ordered during thevisit represented by the current office visit derived record beingprocessed.

As in step 1701, the subroutine first tests for the presence of one ofeight possible single letters, present in the 6th position of thecategory field of the office visit derived record passed from print3a,that indicates that at least lab tests were ordered during that officevisit (see page 8 for explanation). If not then a flag is set, controlis returned back to print3a.prg, and by printing, that office visit isidentified as in which lab tests were not ordered during that officevisit. That information is placed as a detail line in the same way hadthere been actual test results present for printing. If one of the eightis present but the corresponding out-patient lab record is not found,another type of flag is set, control returned to the main program,print3a.prg, and a data error is printed along with that office visitinvoice.

In either of the above two cases and once the reason why there is no labdata associated with that visit is printed, the main program skips tothe next record and if not end of file repeats the above process.

If one of the 8 is present and that out-patient lab record is found thatis associated with the office visit represented by the office visitderived record currently being processed, the lab record identifyingdata is saved. Then, as is seen by step 1706, the subroutine within aniterative loop processing tests each of the 14 lab test field of thatlab record for the presence of any data since a lab test not done willhave its respective field blank. For every field found to be blank (testnot done) a fixed number of blank spaces are stored to each of thededicated variables that hold the separate aspects of each test resultthat were spoken about before. And as mentioned before both the resultdata, and in cases where the test wasn't ordered just blank spaces, arein the same position relative to other test results (or blank spaces) inthose variables as they are in the lab test record. (see step 1708). Andas mentioned before the `dedicated variables` store lab test name,abnormal results numerically expressed, encoded duration of abnormality,comparison to any previous result for that out-patient's test, and fornormal results the date and result for that most recent test if on file.

As in step 1711, if data in that field is found, the above aspects arestored; test name, its lab record field number, literal textcorresponding to each of the three parameter codes (duration, intensity,comparison to previous result) and the actual abnormal result expressedas a decimal number. If the data in that field indicates a normal resultthen a test is made on that field to further determine if a prior resultof that test is on file for that out-patient. If there isn't a priorresult for that normal test result then a flag is set for use back inthe main program, print3a.

If the test indicates a prior result then the subroutine skips back onthat out-patient's lab records to access the most recent result for thattest. In this way for every normal test result an effort is made to findand access most recent test data for that lab test. Also the date ofthat most previous result is accessed for printing in print3a.prg..

After each of the 14 fields of that lab record associated with thecurrent office visit record being processed has been tested, each of thededicated variables will contain an amount of actual data that dependsupon how many tests were ordered but at all times and regardless of theactual number of tests ordered and done, each of the dedicated variableswill be filled to the maximum at the end of the digout2.prg because ifthey aren't filled with actual results, they will be filled with blanks.In any event and after any lab record is processed control is passedback to print3a.prg and resolution of what was done is made, results areformatted for printing and each detail line correspons to one lab testresult.

Referring to FIG. 34, an interactive pre-written query entitledcaseload.prg for determining both the incidence of any chronic diagnosisamongst the database population of out-patients and what percentage ofthose patients with that diagnosis are under the care of any givendatabase doctor.

The routine is a form of bias check by monitoring whether or not thereis a balanced distribution of any one disease entity amongst thenon-specialist, primary care doctors of this database.

As is seen in step 1801, the program first displays an explanatorymessage that orients the user. Then, under the influence of a prompt,both a chronic diagnosis (exactly spelled) and the name of the databasedoctor are entered. On the basis of the diagnostic text entered, thesystem's chronic diagnosis table, chrmed1i.dbf, is searched and itscorresponding full 6 digit code is accessed. The system's master medicalfile (medicl.dbf) is then opened and by use of that 6 digit code a countis made on the total number of out-patients on the database with thatdiagnosis as one of three possible ones for every out-patient.

As in step 1809, a further effort is made to determine the percentagedistribution of that diagnosis amongst the three diagnostic categories.If the diagnosis entered is from a category A then all patients withthat chronic diagnosis are Category A out-patients. If a category Bchronic diagnosis is entered then the out-patients with that diagnosisand who have two others from category B are considered category Aout-patients (see description of FIG. 3, chrmed1i.dbf). For thoseout-patients with that B diagnosis but no category A diagnosis andwithout two other category B diagnosis, they are by definition categoryB out-patients. If the diagnosis entered is from the category C zone(the letter C is first of the six digits), those out-patients with thatdiagnosis and two others from category C are considered from Category B.If any of those patients with that category C chronic diagnosis alsohave a category A diagnosis then they will be considered a category Aout-patient and if any of them have a category B chronic diagnosis theywill then be considered a category B out-patient. If any out-patientwith that category C chronic diagnosis has at most only one othercategory C diagnosis, that out-patient is a category C out-patient.

It is this `weighted` type of valuation, where not only the highestlevel diagnosis determines the diagnostic category but the total numberof diagnosis from any one category that can also determine thediagnostic category classification of the out-patients, for the purposeof group specific data processing.

After the total out-patient count is computed and then any furtherbreakdown into separate diagnostic categories for non-category A chronicdiagnosis entered, a separate additional count is made on the doctorentered to determine first what percentage of all those out-patientswith that diagnosis are under the care of that doctor and then thepercentage distribution by diagnostic category for non-category Adiagnosis within the total for that doctor.

In summary, caseload.prg generates two types of counts. One totallingthose out-patients on the database with that chronic diagnosis enteredand expressed as a percentage. In cases were the diagnosis entered isnon-category A, then a breakdown into separate diagnostic categoriesdepending upon any other diagnosis any of those out-patients may have isalso done and is expressed as a percentage. The second type of count,what percentage of those out-patients with that diagnosis are under thecare of the database doctor entered, is specifically for determining ifthere is any maldistribution or imbalance between the incidence of adiagnosis and any of the database doctors; is there either an overamountof patients with any given diagnosis currently under the care of aparticular doctor or of equal concern a serious underamount of patientswith a diagnosis or several diagnoses that are under the care of anyparticular doctor.

After the percentages are determined for both types of counts, asubroutine is called entitled print4.prg that screen displays them in apercentage format.

Referring to FIG. 35, a subroutine entitled print4.prg called bycaseload.prg after it generates the count data. It organizes and formatsthe data for expression into percentages and integers for both thechronic diagnosis and the doctor entered, along with any breakdown intocategorys for both, and then routes it to the screen for display.

As is seen in step 1900, the subroutine first tests to see if anyout-patients at all have the chronic diagnosis entered and thereforeresulted in the passage of data from caseload.prg. If there isn't any,an appropriate message is displayed the program pauses for the user andthen returns to the main program for another entry or quits. If thereare out-patients on the database with that chronic diagnosis entered atthe prompt then, as in steps 1906 or 1907 or 1908, depending upon whatdiagnostic category it is in, that information is then displayed. Thenthe total number of out-patients on the database with that chronicdiagnosis are displayed as both an integer or absolute number and as afraction of the total out-patient's. If the doctor who was entered atthe prompt does not have any patients with that diagnosis, thatinformation is also displayed. If the doctor does, the usual case, thena number appears alongside the doctor name indicating the number ofpatients who do that are under that doctor's care, and what fraction ofthe total out-patient population on the database does that number ofpatients represent.

That last fraction is very important for determining if there is animbalance anywhere between any particular doctor and the number ofpatients that doctor has or doesn't have with a particular diagnosis. Ifthere were many doctors yet its found that over 50% of the out-patientswith a particular dx are under the care of only one of them, that wouldbe cause for concern.

As is also illustrated, for any B or C category diagnosis thepossibility naturally exists that it may not co-exist with a higherdiagnostic category diagnosis in a patient (see page 24) or with twoother chronic diagnoses from the same category which would then makethat diagnosis alone the sole determinant of what diagnostic categorythat out-patient is in for the purpose of group-specific dataprocessing.

After displaying the above data, the program pauses to allow the usertime to review and then return to the main program, caseload.prg, ismade to allow the user another query or to quit the routine.

Referring to FIG. 36, another pre-written query routine entitledmeditoxi.prg for generating narrowly formulated, summary type clinicaldata. It serves a surveillance function by monitoring for impending,early or actual medication-induced toxicity by reporting out the resultsof patient lab tests known to reflect the potential side effects ofcertain drugs. For any out-patient on a given medication and under thecare of a given doctor, all the results for a given lab test inchronological order are generated and displayed for the purpose ofindicating any early, impending or actual medication-induced tissuedamage as reflected by abnormalities in the results of certain labtests.

As in step 2001, the program begins with an explanatory or orientationmessage. Then a prompt appears for entering both medication name anddoctor name. A search is then made on the system's medicine inventorytable (see FIG. 12, med₋₋ list.dbf) by use of the medication nameentered and on that basis its corresponding 5 digit code is accessed. Asin step 2007, the out-patient master medical file arranged by doctor isthen searched for those out-patients under the care of that doctor whoare currently on that medication. If there aren't any such out-patientsi.e. none under the care of that doctor who are taking that medication,then a message to that effect is displayed and the program returns tothe top to allow for another entry by the user. If there are, then theamount of that medication that each of those out-patients are taking(which may vary even widely from patient to patient) are accessed fromtheir respective records from the master medical file (medical.dbf) andsaved temporarily. As is seen in step 2009, a list of all those patientsof that doctor who are currently on that medication is then displayed byboth name and out-patient I.D. number, and the system laboratory file isopened in preparation for a search.

The user then decides what out-patient is to be monitored and thenselects that patient by the I.D. number next to that patients name. Thenthe system's 14 lab tests are displayed for selection, the assumptionbeing that the user, presumably a doctor, knows what lab tests are mostspecific for detecting any tissue damage caused by any particularmedication (some drugs damage the kidney, some the blood cells, etc.).Upon selection of a lab test, all the numeric data and test dates forthat lab test that are on file for that out-patient just selected aredisplayed.

After a review of the results the user then returns to that previouslist of out-patients of that doctor initially entered and who arecurrently on that medication also initially entered, along with theamounts of that med those patients are currently taking. The user canmake another patient selection or quit the program.

As is evident, there is no subroutine with this program.

Referring to FIG. 37, another pre-written query routine that generatessummary type, narrowly formulated clinical data. It is entitledHeartmed.prg and produces for screen display both physical andmedication data from office visits of out-patients who have chroniccardiac disease and who were seriously symptomatic at the time of thevisit.

The program processing is triggered by and the out-patient group isselected by the name of a database doctor selected and entered, that isall that's required.

The program begins with a message and then a prompt appears for theentry of the name of a database doctor (correctly spelled). The system'soffice visit file, encounte.dbf, is then searched on that name and foreach of that doctor'records a test is done to see if that record meetscertain criteria for inclusion in the further data processing. Thatcriteria includes a clinical status of 3 indicating a lot of symptomsand very active disease, the main reason for the visit is a chronicheart disease diagnosis of a variety of types (the second character inthe condition code field has an `H` indicating heart disease, while thefirst character indicates the diagnostic category of the diagnosis),medication activity of some type occured during that visit and thevisits themselves occuring no more than two weeks from the date ofprogram run.

As in step 2106, any physical data found in the records are accessed andsaved. Then the 5 digit codes from the records representing the signsand symptoms that constitute said physical data are used to search upontheir respective tables (see findings.dbf FIG. 10 and CC₋₋ list.dbf,FIG. 11) and access from them the literal text of each sign and symptomfound in encoded form in that office visit record. As in step 2117, andin order to find and access separately the medication data from thatoffice visit, a subroutine medget.prg is called for that purpose. Uponreturn, a detail line is printed identifying the visit and patient andthen beneath that the physical data consisting of any signs and symptomsdocumented during that visit. At that point, as in step 2111, themedication data passed back from medget.prg is then tested for the kindof change that occured, and then each of the three possible medicinesinvolved are accessed individually for name, type or change and amountinvolved. That data is then formatted and printed below the physicaldata.

The program next skips to the next office visit record. If it's of thesame database doctor, whether or not its from the same out-patient, thatrecord is again tested for the above mentioned criteria and if met thesame processing is repeated. Once another doctor's office visit recordis encountered, the program returns to the top and pauses to allow theentry of another doctor's name or if the user chooses, quit the routine.

Referring to FIG. 38, a subroutine entitled medget.prg called from theprevious main program heartmed.prg for the purpose of finding, accessingand passing back the medication activity data generated during theoffice visit currently being processed.

It begins by opening the system's `transactional` medication file (seeFIG. 9, medicine.dbf) and uses the current office visit invoice tosearch for the medicine record linked to the current office visit recordin order to access the medication activity data. Up to three medicationsmay be found in that linked medicine record and for each found thecorresponding 5 digit code is accessed. That is then used to search onthe system's medication inventory file (med₋₋ list.dbf) to obtain thetext or generic name of that medication. That linked medicine record isre-accessed and for each of the 3 fields holding data, both the type ofactivity (addition,change,etc.) and the amount involved. At this pointall the necessary elements are accessed; medication name, type ofactivity and amount for each of the three possible medications involved.They are then stored to a single variable for passage back toheartmed.prg.

Back in heartmed.prg each of the medication data present areindividually accessed from the passed variable, then formatted andprinted for screen display.

Referring to FIG. 39, the main calling program entitled labfirst.prg forout-patient lab record creation and test data entry. During the courseof this type of processing several lower-level programs are called atvarious times for executing specialized functions.

This program initiates the processing by first prompting the user forout-patient I.D. no., date of test(s) and for indicating if test(s) wereordered during an office visit (as opossed to emergency room). A searchis then made on the lab file for a prior lab record of that out-patient.If not found the operator may re-check the I.D. no. and/or continue withprogram processing since it may well be that out-patient's first labrecord. As in step 2308, if the tests were ordered during an officevisit the last (most recent) record for that patient is found and thatoffice visit invoice is accessed. If it's indicated that the tests wereordered during an emergency room visit the emergency room file isprocessed in the same way.

In either case, a prior source record, whether it's an office visit oran emergency room visit, must be on file in order to obtain the sourceinvoice that will provide the cross-link between the source and the labrecord storing the results of the tests ordered during that sourcevisit. If neither record can be found the processing for thatout-patient is aborted and the program returns to the top for anotherout-patient data entry. Once an originating source invoice is found thelab file invoice is incremented automatically in a separate step inpreparation for a new lab record creation. The next level program,labentry.prg, is then called.

Referring to FIG. 40, a main subroutine entitled labentry.prg called bylabfirst and which serves as a central control and access point forfunctions necessary in obtaining information about prior results fromvarious aspects for each lab test result, both abnormal and normal, andhow to load the various types of data, both actual and encoded, duringthe data entry process.

It begins with an orientation message for user guide. At this point anew lab record is created and appended, then loaded with the identifyingdata already obtained; out-patient I.D. No., date of test(s). new labrecord invoice and source invoice(either office or e.r.). The lab file,abn₋₋ lab.dbf, is then closed with the record pointer value saved forlater access back to the newly created lab record for loading testresults, etc.

As is seen in step 2404, the user is then presented with options as towhat general action to take; access prior information of each lab testwhose result is present and to be loaded, access the program's Help filefor assistance in encoding the various historical and comparativeresults of each lab test into a compilation of prior results called`Parameter` data that are placed in the segment of the lab test fieldnext to the actual results, and finally the option to activate acustomized data entry screen for use in data loading.

Normally, the user would, as in step 2407, first select accessing priortypes of information for each test result present. If that selection ismade, as in step 2410, a list of all the 14 lab tests are displayed witheach assigned a unique number for individual access. Then, after any labtest is selected, a list of options are displayed for obtaining severaltypes or perspectives of prior information of that particular lab test,a kind of `track record` of that lab test. These prior aspects consistof 4 options presented on the screen but exist as two groups of twoeach, as seen in steps 2412 and 2414, and each group of two functions,as seen in steps 2413 and 2415, requires accessing the same of twosubroutines in which two of the four aspects of prior information may beobtained. (to be discussed in detail later). After such a composite ofprior information for each test is obtained, the help file can beaccessed. This will assist the user in choosing from amongst a number ofpossibilities the appropriate 3 single letters that together constitutea retrospective ` composite` and is referred to as `parameter` data foreach lab test result, being loaded along with it into a segment of thesame lab test field. The three parameter codes are; duration of abnormalresult(how long has that test been abnormal), intensity of theabnormality and comparison to any most recent result for that test.These codes are only for loading with an abnormal test result. For eachnormal lab test result a letter indication in the first field positionfor indicating `normal` result and then one of 3 possible letters in thefourth position of that lab test field depending upon an abnormal priorresult, normal prior result or no prior result on file for that test.

After obtaining prior information from the several aspects for each ofthe test results present for data entry, as indicted by steps 2412 and2414, and then selecting the appropriate parameter codes depending uponthe prior information or `track record` of that lab test, the customizeddata entry screen is then activated and the actual results along withthe parameter data are loaded into each of the lab test fields of thatout-patient's newly created lab test record. And as has been discussedfor each lab test present for loading there are two types of informationto be loaded; the actual result both normal and abnormal and theparameter data that encodes prior information about that out-patient'slab test from several aspects.

With abnormal test results, the numeric or quantitative result occupythe last 4 positions of the field while the first 3 are occupied by theparameter codes. In the case of normal results, only an indicator in thefirst position and one of 3 in the fourth position(as a parameter code)for indicating any most recent result for that test.

The discussions beginning on the next page elaborate upon the twosubroutines already mentioned here and called by labentry.prg that areused to access prior historical and comparative information for anyout-patient lab test.

It's important to keep in mind that just prior to choosing what aspectof prior information on that lab test to look for the lab test itselfmust be selected first. That's made possible by listing them first inthis subroutine with numbers alongside the name of each of the 14 labtests, and by selecting one first by that associated number, that is theparticular lab test searched for, accessed etc. when the selection ofprior result from one of several aspects is made just after that.

Referring to FIG. 41, a lower-level subroutine entitled findout1.prgcalled by the main subroutine labentry.prg just discussed, and is forthe purpose of finding and accessing prior information on any of thesystem's 14 lab tests from 2 perspectives that were selected for in thehigher level subroutine labentry.prg that called it. In this subroutinethose two prior aspects are; the date and value of the last abnormalityfor any lab test and the date and value of the first anormality(at leastfor the current file). The data is routed to the screen and therebyenables the user to interpret the information and then determine whichof several possible single letters to choose from in order to encode forthose two prior aspects as part of the parameter segment of the lab testfield.

The subroutine begins by first opening the lab file(abn₋₋ lab.dbf) andpositions the record pointer to that out-patient's newly created labrecord. As is seen in step 2503, it then skips back one record and ifthat isn't a record for that out-patient a message is displayedinforming the user that a search on that out-patient's prior lab testsis not possible(because there aren't any). If there are earlier recordson that out-patient present in the lab file the most recent record isaccessed and the date of those tests are displayed for user orientation.At that point, and as is seen in step 2506, the record pointer is thenmoved to that out-patient's first lab record(earliest one on file) inorder to begin the search. If the selection called `first abnormalityand date` was made in labentry.prg, then beginning with the firstprevious lab test record for that out-patient. the first abnormal resulton the lab test selected for by number back in labentry.prg that isfound is accessed and the numeric data as well as the date of the testsordered are formatted and displayed along with the lab test name and asa reminder to the user/operator the nature of the data accessed, i.e.date and value of first abnormality, etc.. After a pause the userreturns to the main subroutine, labentry.prg, and can then choose andaccess other kinds of prior information on that lab test or another labtest for the purpose of determining the proper parameter coding.

If the user/operator then selects `date and value of last abnormality`for that lab test, this subroutine (findout1.prg) is again entered.Initially the same steps are involved until step 2513 is entered. Now,whenever a lab record for that out-patient is encountered in whichabnormal data in that lab test field is present the numeric values andthe data are saved. That is repeated for each successive later labrecord in which results for that lab test are found for that out-patientincluding and until the last record(most recent) is found. At that pointand if there were more than one previous abnormal result for that labtest, the values present now represent the last abnormal value and theassociated date since all previous values were written over andtherefore replaced by all later ones as the record pointer skippedforward from that out-patient's first lab record. And once again, inaddition to the numeric and date data displayed, a brief messagereminding the user of the kind of prior information being accessed isdisplayed also. And as in the option whereby date and value of firstabnormality is searched for, if there isn't any abnormal results forthis particular lab test in any of that out-patient's lab records thatare at least currently on file, then a `lab test normal` message isdisplayed. If it isn't on file at all, i.e. this is the first time thatlab test has been done for that out-patient, then that type of messageis also displayed.

Once again, the subroutine pauses for the user to review the data onthat lab test's prior results and then returns to the main subroutine,labentry.prg., for another type of selection for the same or another labtest, loading of test results through the customized data entry screen,access the help file for instructions on how to code the parameter dataobtained by choosing the 4 options while in the labentry.prg subroutine,or returning to the beginning to start another out-patient or to quitthe routine.

Once again, the parameter data are three single letter codes placed inthe same field as the test results and represent 3 types of informationregarding that lab test. The first or most leftward letter is forindicating the length of an abnormality; recent onset, medium durationor chronically abnormal. The second position is for indicating theintensity of the abnormality and the third or right-most position is forindicating what this result is in comparison to any most recent resultfor that test. Since it requires accessing prior information on any testfrom several aspects in order to code for the first and last positionsof the `parameter data`, the resultant data reflects a composite ofprior results and therefore is spoken of as being compiled.

Referring to FIG. 42, the other subroutine containing two main functionsthat is called by labentry.prg. This is entitled findout2.prg and likefindout1.prg this also searches and accesses aspects of prior results ofany lab test. In this routine the nature of the information obtained areof two other types from that in findout1.prg; consistency of a lab testresult and the result of its most recent test.

As is seen in step 2601, it begins by positioning the lab file to thatout-patient's newly created lab record and then skips back one to see ifit isn't the first for that out-patient. If it is, that kind of messagewould be displayed to notify the user to end any prior search.Otherwise, the record pointer is positioned to that out-patient's first,earliest lab record on file and the type of further processing willdepend on which of the two above mentioned aspects of prior lab resultsand information was selected in labentry.prg.

If `most recent result` was selected then, as in step 2627, a searchbegins on that lab test field of that out-patient's lab records. At thefirst indication of any results at all on that test, a flag is setindicating it was at least done before. For each subsequent lab recordfor that out-patient in which results on that test are found, the value(numeric) and date are saved and then are over-written by any subsequentresults found for that test amongst any later lab records for thatout-patient, until that out-patient's last record. At that point and asin step 2630 the fact of a prior result, its value and date of test aresaved. The data is then tested and either one of three possibilities asto the result, as illustrated in steps 2621 or 2623 or 2625, isdisplayed as a message.

If `consistency of results` was selected in labentry.prg the sameinitial processing occurs. However, and as seen in steps 2613 and 2611,for each record in which test result data is present in that lab testfield, either one of two counters are set and incremented each timedepending upon whether the result is normal or not. At the end of thelab records for that out-patient, the condition of the two counters aretested and depending upon whether or not both are zero, non zero or justone is zero, the appropriate message is displayed along with any lasttest date, see steps 2626, 2620, 2618, 2616.

Once again, the subroutine pauses for user review of the displayed dataand then will return to labentry.prg for another selection for the sametest, another test, etc. The options regarding what the user can do areidentical to the previous subroutine, findout1.prg., at this point.

Referring to FIG. 43, a main calling program entitled Doctorpg.prg thatcalls other lower-level subroutines for the purpose of accessing anddisplaying lab test results of individual out-patients from more thanone perspective and in the context of other clinical data documented atthe time the tests were ordered from office visits. The program and itssubroutines are built upon and represent a variation of the multi-levelprogram beginning with labfirst.prg responsible with creating andloading out-patient lab test results. But since this program is designedfor querying or inquirying into patient lab data intead of data entry,it lacks a record creation and loading routine but includes a processfor cross-linking a lab record with its `parent` office visit(record)from which the test(s) were ordered.

There are two different ways of viewing the data depending upon userpreference; Either by all lab test results done from the same officevisit or by individual lab test results for an out-patient from severalprior aspects (as in findout1.prg and findout2.prg).

The program begins by displaying an orientation message for the user.Then either of the two above options are selected. As in step 2704, theout-patient's last name and at least the first initial is entered. Then,and again regardless of the selection, that out-patient's master medicalrecord is then accessed and from it are obtained patient identifying andbackground data for later use in viewing with lab test results.

If the above selection was to display all test results from a givenoffice visit, the user then enters what he or she thinks or knows to bethe date of an office visit during which those lab tests of interestwere ordered. The office visit file (encounte.dbf) is then searched onthe out-patient I.D.No. obtained when the master medical file(medical.dbf) was searched on the patient name entered at the top of theprogram. The office visit file is also searched on date in order to findand access the exact office visit (record) the user has in mind. If theoffice visit record from that date for that out-patient isn't found theprogram is designed to allow the user to enter another date ad infinitumuntil any record is found, presumably the one the user originally had inmind. Or, after a few trys the user may return to the beginning and viewdata from a different perspective or quit the routine or choose anotherout-patient.

If or when the `correct` date is entered and the desirable office visit(record) is found, the invoice is saved. Now, as in step 2716, by takingadvantage of the dualed invoice nature of the lab record (see abn₋₋lab.dbf), that invoice is used to find the lab record storing lab testresults ordered from that office visit. At that point a call is made tosubroutine digout2a.prg (identical to subroutine digout2 of FIG. 33, sonot shown) for stepping through that lab record and accessing those testresults present. Another call is then made immediately to subroutineprint3b.prg (which is with minor modification identical to print3.prg ofFIG. 32, so not shown) which will access, format and print the detaillines for each lab test result in conjunction with other out-patientoffice visit data. After review the user returns to the top to reviewtest results by the same or other method for the same or anotherout-patient or quit the routine.

If the user selected instead to review individual lab tests for thatout-patient then the entry of a date is by-passed and a main subroutine,selectpg.prg, is called that is virtually identical to labentry.prg ofFIG. 40. And as in that subroutine, allows for and controls both theselection of individual lab test results for viewing and from what prioraspect of results for that test; first and last abnormality and dates,consistency of result and most recent result, etc. And upon return ofcontrol from the main subroutine selectpg.prg the user may return to thetop to select another method of viewing different data for the sameout-patient or another out-patient or quit, etc.

Referring to FIG. 44, a subroutine entitled selectpg.prg that is calledby the highest level program doctorpg.prg discussed just previously. Itis activated if the user, while in doctorpg.prg, has chosen to view theresults of individual lab tests and from several prior aspects, as hasbeen defined before except for an additional aspect of prior resultsdeveloped specially for this inquiry type of routine. In here and unlikebefore, the largest and smallest abnormal result for any lab test andthier respective dates are determined, accessed and then displayed asanother option for the user to select.

The subroutine begins by listing all 14 numbered lab tests available forselection. Then, as before in labentry.prg (FIG. 40), the user firstselects a lab test and is then presented with a menu or list of optionsas to prior aspects of results for that lab test of that out-patient. Ifthe prior aspect of results involving the `largest and smallest abnormalresult` is selected then program control remains in selectpg.prg and astandard `bubble sort` is executed, as is seen in steps 2825-2832. Thenas in step 2820 data from both the largest value and the smallest valuevariable are displayed with their respective dates. If on the other handan abnormal result for that test isn't found for that out-patient, thatmessage is displayed shortly after the selection. If however there isonly one abnormal result on file it will be displayed as both largestand smallest but since the dates are shown as well there shouldn't beany confusion.

The program then pauses to allow the user to review and then a return ismade back to the top with a complete listing of all the numbered labtests. The user can then view another prior aspect of results for thatlab test or choose another lab test for that out-patient, or return backto the top of the main calling program, doctorpg.prg, for anotherout-patient or to quit.

If the user chooses any of the four other options regarding prioraspects of any lab test result that were described and illustratedbefore in labentry.prg, either the subroutine finda1.prg or finda2.prgare called and entered. However, since they are virtually identical infunction and design to findout1 and findout2 already discussed (seeFIGS. 41 and 42) in connection to the lab record creation and dataloading, there isn't any need to show them in the same way except to ofcourse mention them as existing and in connection to what particularroutine.

Referring to FIG. 45, an upper-most calling program entitledaddencrc.prg that controls, through calls to separate lower-levelsubprograms, the creation and data loading of the office visit record(encounte.dbf)

It begins by collecting the out-patient I.D. No. and then having theuser indicate whether or not an acute, temporary `new problem` was themain reason for that office visit (i.e. the 6 digit condition code isfrom the short term diagnosis table, er₋₋ list.dbf). As in step 2902, asearch is then made on the office visit file, using the patient I.D.entered, for a prior record of that out-patient.

If a previous record for that out-patient is found the program thendisplays guidelines as to what clinical status may be entered dependingupon what the most recent status for that patient's office visit was. Ifthere is a conflict the user may return to the top to enter anotherpatient or quit the routine. If there isn't a conflict the status valuefor that office visit is entered and then a call to the firstlower-level subprogram, part1.prg, is made for the actual recordcreation and more data loading (more of this later). Upon completion ofprocessing in part1.prg, control is returned to this highest levelprogram. If there are any physical data present for loading then anothersubprogram call is made from addencrc.prg to part2.prg for the entry ofencoded physical symptoms data. And if any physical signs data arepresent for loading then another call is made to part3.prg when controlis returned back to addencrc.prg from part2.prg

At each point subsequent to the part1.prg call, and as seen in 2908 and2911, the determination of any need to call further subprograms is madein this most upper level program, either into a lower-level subroutineor, as in steps 2909 and and 2912, back to the beginning for anotherout-patient record or to quit.

If a prior office visit record for that out-patient doesn't exist, i.e.a first time office visit for a new database patient or the wrong I.D.NO., the user will resolve that. If it represents a new out-patientrecord then the subprogram for a new out-patient, first time recordcreation, is entered, named addnewrc.prg. This program will then in thatcase act like this one, addencrc.prg, as the controlling program forcalls to the same lower level subprograms just like this one. Uponcompletion of a first office visit record, control once again returnshere first as in step 2922, and then back to the top for another record,step 2901, or the user may quit.

As in steps 2914, 2915 and 2916, if this main calling program has beenexecuted beyond part3.prg a data check is made to ensure that in anynon-status 1 records there are at least one physical data item present.That at least either one sign or symptom in encoded form be present forentry. That is a requirement since the clinical status of theout-patient at the time of the visit is by definition of an unstablenature, i.e. something is clinically wrong and there is some diseaseactivity of some type. Therefore, the requirement that for everynon-status 1 record at least one sign or symptom be documented duringthat visit and then transcribed for the purpose of data entry duringthis program. And if that isn't the case then that record is deleted forthat out-patient and control is returned to the top for anotherout-patient record creation or quit the routine.

Referring to FIG. 46, a main subroutine entitled addnewrc.prg, called bythe main program addencrc.prg just discussed, for the creation andloading of a new out-patient office visit record (first time). And asmentioned it acts like a main calling program by calling on lower levelprograms depending upon how much data is present for loading into a newpatient office visit record (it depends of course on what is found andwhat the doctor did).

After receiving control from addencrc.prg, a message is displayedreminding the user this is the first record to be placed on file forthis new out-patient. The clinical status number is entered and thencontrol is passed to part1.prg for actual record creation and partialdata loading. Then with each passage of control back it determines if aneed for further calls into lower level subprograms are necessary forphysical data entry. As in steps 3005, 3008 and 3013, at the point whereall the data for that first record has been entered it will then promptthe user to indicate if any additional records are to be done. And uponthat basis on return to addencrc.prg, it will either set up for anotherrecord creation and entry or quit the routine.

As in step 3011 and like addencrc.prg, if a non-status 1 office visitrecord is created but there are no physical data at all present forentry it is disallowed and the new patient record is deleted prior toreturning to addencrc.prg.

Referring to FIG. 47, a main subroutine entitled part1.prg that iscalled by add encrc.prg (or addnewrc.prg for a first time record) forthe actual creation and loading it with the essential core ofout-patient data that are the most difficult to access. Duringprocessing of the new office visit record there is also simultaneousupdating of that out-patient's master medical record (and tracking) forany changes to any of that out-patient's chronic long term diagnosis.

It begins by opening the office visit file, positioning to the lastrecord and then incrementing the invoice by one for later inclusion intothe new record. Then, as in step 3104, up to 3 4-digit codes, eachrepresenting the `numeric` segments (last 4 digits) of a chroniclong-term diagnosis (see FIG. 3, chrmedli.dbf), are present for entry atthe designated prompts on the screen.

The master medical file is then searched on that patient I.D. No. Ifthis is a first time record creation for a new out-patient and onedoesn't exist, a new master medical record will be created and the I.D.No. for that patient is written to it. At that point, from step 3110 tostep 3130, the processing involves interaction with or cross-fileprocessing between the newly created office visit record and thatout-patient's master medical record for the purpose of updating anychanges to that out-patient's diagnoses's. As in steps 3110 and 3111, ifa primary diagnosis (the highest level diagnosis) is entered, that 4digit code is compared against the last 4 digits of the primarydiagnosis in that out-patient's master medical record (both records musthave at least a primary diagnosis). If it is the same then the full sixdigit code in that master medical record field is stored to a variablefor later writing to the corresponding position in the newly createdoffice visit record, i.e. cross-file processing. If there is adifference and a 4 digit code has been entered, the chronic diagnosistable is then searched on that 4 digit code and the full 6 digitdiagnosis is accessed and because of the mismatch with that position inthe master medical record, the six digit diagnosis is written to thatdiagnostic position in order to update that out-patient's master medicalrecord during loading of the new office visit record (i.e. cross-fileprocessing). In order to indicate a change in that patient's diagnosisand to keep historical track of such changes, the following takes placein each of the three fields associated with each chronic diagnosis fieldof the master medical record; the new office visit invoice is written toone, a flag is set in another and the current date is written toanother.

If a 4 digit code isn't entered at a chronic diagnosis position (field),the corresponding field in the master medical record storing a diagnosisis stored to a variable for later writing to that same field in the newoffice visit record. That step corrects for any ommission during dataentry of an active, current chronic diagnosis, and naturally applies toall three fields.

Beginning at step 3132 the condition code or main reason for the officevisit is then accessed from the appropriate table for loading to the newrecord. If the new problem flag had been set during the data entry atthe top of the program at addencrc.prg, then the 4 digit coderepresenting the primary reason for that office visit is used to searchon the short-term, acute diagnosis table (er₋₋ list.dbf) and thecorresponding full 6 digit diagnosis code is accessed from the table andsaved for later writing to the newly created office visit record at thecondition code field. Alternately, if the new-problem indicator wasn'tset, that same 4 digit code is instead used to access the chronic, longterm diagnosis table since the condition code field or the main, primaryreason for the office visit represents a chronic diagnosis as opposed toa short term one. Then, as in step 3138, the new office visit record isactually created (i.e. appended) and then all the basic data elementsthat have been written to variables are now written to thier appropriatefields in that new record which includes; the 6 digit condition code, upto three 6 digit codes to each chronic diagnosis field, the new officevisit invoice, patient I.D. No., and the clinical status of the patientduring that office visit. As in steps 3115, 3113 and 3114, whenever asearch by a 4 digit code is unsuccessful, a message is displayed and theuser may return to either the start of this subroutine or to the startof the main program.

If the search useing the 4 digit codes are successful in finding andaccessing from the appropriate table the corresponding full 6 digitdiagnosis and there are no other problems, control is returned toaddencrc.prg (or addnewrc.prg for a first time record) and a flag willbe set to allow passage to the next lower level subroutine, part2.prg,for the entry of any physical data present.

Referring to FIG. 48, a lower-level subroutine entitled part2.prg calledby addencrc:prg (or addnewrc for a first time out-patient record) forthe entry of any symptoms or complaints data to the office visit record.(signs or findings data are entered during part3.prg) This subprogram iscalled after part1.prg and from within addencrc.prg or addnewrc.prgdepending upon prior processing of that out-patient's record data.

The extent of processing within this subprogram is naturally dependentupon the presence of any physical symptom data for entry and if thereis, it then employs two separate methods for entering that datadepending upon the way in which the source document was prepared.

It begins by displaying an orientation message about how to use theroutine depending upon the way the data was transposed to the data entrysource document from the medical department. At step 3203 another checkis made to exclude from the office visit file the addition of anynon-status 1 records that don't have any physical data for entry (eitherit wasn't documented during the visit or it was lost during thetransposition to a data entry source document). Beginning at step 3204and depending upon how the data for entry has been prepared, either a 3digit code for up to two complaints is entered by directly taking it offthe source document or alternately the clinical group indicator of thatcomplaint (what organ system its from, i.e. cough=lung) alone isentered.

As is seen in step 3213, the former case is quicker since it involvesless steps. The complaints or symptoms table (see FIG. 11, cc₋₋list.dbf) is opened and searched on that 3 digit code in order to accessthat physical complaint's full 5 digit code. As a non-binding check ondata consistency, the single letter group indicator of the 5 digitcomplaint code is compared to that of the 6 digit condition code thatwas already loaded in part1.prg, since it should be identical assumeingboth a diagnosis of any problem and any symptoms that result from saidproblem involve and emanate from the same organ system. If not identicalthen a brief message is displayed about that non-match but the programwill still write the 5 digit complaint code to the new record. Asmentioned, the system and program provides for two physical complaintsto be entered into the office visit record. At step 3219 the user mayreturn to the top of this subroutine for entry of the second complaintif present, by either the same method or the alternate method to bediscussed below, or return to addencrc.prg..

If the clinical-group indicator method is used, there are two main stepsinvolved. First, upon entry of the single letter for indicating thegroup, a listing is generated for display that includes all complaintsfrom that group. The complaints that are displayed are represented as anentire table entry, i.e. both the 5 digit entry and the literal text(i.e. `chest pain`) contained in a 25 character field. In that way theuser can visually search the displayed list in order to find a matchbetween one of the text's displayed and that appearing on the sourcedocument in written form and associated with that single letter forindicating clinical group (see FIG. 50). Once a match is made betweenthat complaint within the group originally listed on the screen byentering that single letter and that written on the source document usedfor data entry, the last 3 digits of that 5 digit code associated withthe literal text of the complaint that has been matched is taken off thescreen by the user and then entered at the prompt. At this point thesame processing then occurs as with the direct method because now that 3digit segment is used to search on the system's complaints or symptomstable (CC₋₋ list.dbf) for accessing the full 5 digit complaint code andwrite it into the appropriate field position of the new office visitrecord. The user may then return to the top of this subprogram to enteranother complaint for that out-patient documented during that officevisit or return to the top program addencrc.prg for another out-patientoffice visit record creation.

It should be noted that complaints and symptoms are the same thing andfindings and signs are the same thing.

Referring to FIG. 49, a subroutine entitled part3.prg called byaddencrc.prg (or addnewrc.prg) for the entry of any physical signs(findings) documented during the office visit whose record is currentlyunder creation and loading.

Except for the fact that these data items are clinical findings such as`tenderness` as opposed to a clinical complaint of `pain in the stomach`and therefore another type of table is used (i.e. findings.dbf, see FIG.10) everything else is exactly the same as to the structure of datatypes, alternate types of access as described in FIG. 48 and method ofprocessing as discussed in part2.prg.

Also, as in part2.prg, upon completion of the data entry control ispassed back to addencrc.prg or addnewrc.prg for either creating anotherout-patient record or terminating the routine.

Except for what is represented by the data types, complaints or symptomsvs, findings or signs, part3.prg is virtually identical to part2.prg.

Referring to FIG. 50, a model source document used in loading a centralcore of office visit data during the record creation subprogrampreviously discussed and as represented by the previous FIGS. 45-49.Only those data items involving the greatest complexity in locating,accessing and over-all processing were selected for illustration, whilethe rest can be transcribed directly.

As mentioned at several places before, the newproblem field is forindicating if an acute, temporary and as yet not fully characterizedproblem was the main, primary reason for the office visit. In effect,was it the chief complaint as opposed to one of that out-patient'schronic, established diagnosis? Then, if the field is set to trueindicating that is the case, the table from which the 6 digit conditioncode is obtained is the acute diagnosis as opposed to the chronicdiagnosis table. The clinical status field contains a single digitnumber from 1-5 and is for indicating whether or not there is anysignificant disease activity and to what relative extent. (see FIG. 4,encounte.dbf). The three fields mcode1, mcode2 and mcode3 are for thethree possible chronic diagnoses any out-patient may have with mcode1being the primary diagnosis since it is from the upper-most position ofthe Chronic Diagnosis table relative to any of the other two (see FIG.3, chrmedli.dbf and how it is arranged in ascending order of urgency orclinical priority).

That aspect of any diagnosis that is transposed to the source documentfor data entry is the last 4 `numeric` digits of the full 6 digitdiagnostic code and which is, as an inspection of the chronic diagnosistable (chrmedli.dbf) shows, the most unique aspect of each encodeddiagnosis. Similarly, the condition code field, whether acute orchronic, is entered as a 4 digit code whereupon the full 6 digit code isthen accessed as discussed before. And as mentioned here if the newproblem field is set to yes or true then the 4 digit code present in thecondition code field of the source document will be directed by theprogram to search on the acute, short term diagnosis table to obtain thefull 6 digit diagnosis code (see FIG. 8, er₋₋ list.dbf)

As already shown, the physical data (signs and symptoms) may berepresented on the source document in two different ways reflecting twodifferent methods of entry. The most direct method is the one labeled`first method` and in which the last three digits of either thecomplaints (symptoms) or the signs (findings) are entered directly andused to search for the full 5 digit physical data item because it is themost unique encoded aspect of it. The alternate or indirect secondmethod involves both a single letter as the clinical group indicator andthe presence of the full literal text of that sign or symptom exactly asit exists internally within the two physical data tables (see cc₋₋list.dbf and findings.dbf FIGS. 10 and 11).

All of the above data found on that source document would be prepared bya trained medical staff familiar with and trained to locate thosephysical data items by either a frequently used hard copy in which thosedata items are sorted or arranged on a medically logical basis or readyaccess to a computer based listing of data from the relevant tables.

At the end of a normal day these source documents would be collectedfrom the offices of each primary care physician and all transmittedtogether to the data entry personnel for transcription and other dataentry operations.

Referring to FIG. 51 a main computer program entitled addmedrc.prg forthe creation and loading, i.e. data entry, of the out-patient mastermedical record. As in the office visit record creation routine, onlythose data items most difficult to locate, access and over-all processhave been included in this data entry process as well.

It begins with an orientation message for the user. A counter is thenset to remind the user of the current total of chronic diagnosis enteredby screen. Then, as in addencrc.prg, depending upon the way in which asource document has been prepared the user may enter a diagnosis in twodifferent ways. It may be either a 4 digit code as the direct method orin the indirect method 2 single letters; one defining the diagnosticcategory and the other the clinico-pathological group of the chronicdiagnosis to be entered. In this latter case the purpose is to generatethe narrowest possible list of chronic diagnoses's for making it easierfor the user to identify one amongst that list as a visual match withthat present on the source document. It is for facilitating a visualsearch until a match is made between two diagnosis's, one on the screenand the other present on the source document.

Briefly, and as in step 3504, when the first or direct method of chronicdiagnosis entry is used, the 4 digit code is used to search on theChronic diagnosis table and if found the full 6 digit diagnostic code isaccessed and temporarily stored. The program's diagnosis counter is thenincremented and the number of diagnosis already entered is displayed.Return is then made to the top for another chronic diagnosis entry or toquit.

As in step 3505, if the second, indirect method is used, theclinico-pathological group letter must be used while the diagnosticcategory letter is optional, although by useing that too the listgenerated for the visual search will be smaller by a factor of threesince there are 3 diagnostic categorys. As in step 3521, the uservisually searches for a match between the written diagnosis on thesource document present with the single letter indicators for the twogroups and that from amongst the list generated on the screen by programprocessing when each letter from the two groups were entered. When amatch is found the last 4 digits of the 6 digit code is copied from thescreen by the user, entered, and as in the first method the chronicdiagnosis table is searched, the full 6 digit code is accessed andwritten to a variable for temporary storage.

Regardless of the method of entry used, each time a diagnosis is enteredthe program counter is incremented and when all the ones on the sourcedocument have been entered and before the user can by-pass that entrystep the program will check to see if at least one diagnosis has beenentered. If not a message is displayed and the user must return to thetop. If the diagnosis check is o.k. the program still pauses to allowthe user opportunity to check what has been entered against the sourcedocument, etc. If everything is o.k. the out-patient's name and I.D. No.are entered. The master medical file is then opened and a search on thatI.D. No. is made. If found a message `patient record already on file` isdisplayed and processing on that out-patient ends, there is no recordcreation. If not found then a new master medical record is created(appended) and both name and I.D. No. along with all the chronicdiagnoses's previously entered (up to three) are then written to the newrecord.

At that point a subroutine is called, checkrec.prg, to ensure that incases in which more that one diagnosis was entered, they are sequencedin relation to each other according to their relative position in thechronic diagnosis table; primary dx highest, secondary dx next highest,etc.

Upon return from that subroutine, control is passed to step 3509 foranother try, another out-patient, or terminate the routine.

Referring to FIG. 52, a subroutine entitled checkrec.prg called byaddmedrc.prg to check on the data integrity of the chronic diagnosisdata entry of that main program. It ensures that the proper ordering orranking of the chronic diagnosis as they were entered into the newmaster medical record was observed during addmedrc.prg, i.e. the dx fromthe highest position in the chronic dx table relative to any of theothers is in the primary position and the second highest is in thesecondary position, etc.

In order to test for the above and as step 3601 shows, the value of thelast 4 digits of the primary dx diagnosis is compared against that inthe same position of the secondary dx field. If it isn't greater then acomparison is made between that secondary dx's last 4 digits and that inthe identical position of the tertiary dx field. If that value alsoisn't greater then it is assumed there are three entered and they aresequenced properly in relation to each other based upon their relativepositions in the chronic diagnosis table. If the value of the 4 digitsfrom a higher level dx is found to be higher than that from a lower oneAND it isn't due to blank spaces, an error message is displayed, thatnew master medical record, loaded incorrectly, is deleted and control isreturned to addmedrc.prg for another try, another out-patient or exitthe routine.

Referring to FIG. 53 a model source document for use in the data entryroutine of addmedrc.prg, the out-patient master medical record. Onlythose data items most difficult to locate, access and over-all processfor are included in the routine for the purpose of illustration as tothe feasibility and utility of such a method and process.

As in the source document used with the office visit record routine,both methods for entering the chronic diagnosis's are illustrated. Onthe left is the direct, quickest method with samples in each of thethree diagnostic positions. Note that as before it is the last 4 digitsof the 6 digit diagnostic code that is used in this method of directentry and also how the `numeric` value becomes progressively highergoing from primary to tertiary.

The second or indirect method is on the right. Those samples representthe other segment of the full 6 digit diagnostic code since thediagnostic category and the clinical group indicator as single lettersare found. The other aspect of the indirect method is the literal textof that chronic diagnosis for use in the visual search and match, whichis located just beneath the two letters. Note that `compulsory` refersto the clinico-pathological group and the letter representing that mustbe entered and first. The letter indicating the diagnostic category ofthat chronic diagnosis is optional but if used will naturally restrictfurther the number of diagnosis displayed when the list is generated andtherefore make the visual search for that diagnosis matching the onewritten on the source document much easier.

The field for the out-patient I.D. is not shown but as was seen inaddmedrc.prg that data was transcribed (entered) directly at the prompt.

Since there was a full explanation of how both methods of entry operateduring discussion of addmedrc.prg, that won't be repeated here.

Referring to FIG. 54, a main print program entitled overdrawn.prg fordetecting and monitoring overuse of any office based laboratory tests.It reports out in coupled format the results of the same lab testsordered from separate office visits for any out-patient along with thesame salient clinical data from both. In this way, by comparing previousresults and conditions with current ones for that out-patient, one candetermine the legitimacy of lab work ordered during an otherwiseuneventful and unremarkable office visit. Was there a precedent basis orreason for drawing blood work when the clinical condition of theout-patient at the time the tests were drawn would not seem tonecessitate it?

Program specific processing isn't triggered until a `special` type ofoffice visit record is encountered; a status 1 (normal, baseline orasymptomatic) and scheduled visit, a chronic dx as the main, primaryreason for the office visit (condition code field=chronic diagnosis) andyet lab work during that office visit was ordered and drawn despite anunremarkable visit. In the face of that was there any justification fordrawing blood and consuming expensive resources?

Upon that identification for any office visit record and as in steps3807, 3808, 3809, 3810, 3811 and 3825, cross-linkage between that officevisit and the out-patient's master medical record is established forprinting heading and background data once per page. At that point a callis made to a subroutine named digoutod.-prg that accesses all lab testresults from the current office visit just identified as being of`special` type. Then for each lab test result present, thatout-patient's from whatever prior lab record of that out-patient it maybe in (see discussion for FIG. 55, digoutod.prg).

Upon return from the called subroutine, the heading data for that officevisit is printed then, for each lab test result present in the variablepassed from the subroutine, a detail line is printed that includes dateof test and invoice of the lab record. At that point, for comparisonwith previous and identical lab tests of that out-patient along withidentical types of other clinical data from those separate office visitsfor that out-patient as well, the two groups of data from differentoffice visits are printed in coupled format as well for easiercomparisons in order to assess justification for the current blood work.

In summary, each most recent lab test result that corresponds to eachdrawn during that office visit of special type (as defined earlier) isalso accessed and as a result different prior lab records for thatout-patient may need to be accessed. The same applies to each prioroffice visit for that out-patient during which each of those most recentlab tests were ordered, i.e. accessing different prior ones. And onceagain, each lab test result is coupled with its most recent result, ifavailable, and the coupling of printed data also includes the samesalient clinical data from different office visits of that out-patient.

In cases where any prior lab tests were ordered during an emergency roomvisit by that out-patient there is no access of prior lab data and noattempt to compare past with current results, etc. That is because it isassumed any lab test ordered during any office visit type for thepurpose of following up on one ordered during an emergency room visit isprobably justification in itself.

After all the data, coupled and combined, stemming from any office visitrecord meeting the previously defined criteria has been printed theresultant detail lines that were generated are separated by a brokenline and the program then skips to the next record. If another of thesame, special type is encountered and identified and it is the sameout-patient, the resultant detail lines are printed below the previousones. If it is another out-patient then the program skips to the nextpage, prints heading and background data and repeats each detail linefor each lab test result. Processing continues until end of office visitfile is encountered.

Referring to FIG. 55, a subroutine entitled digoutod.prg calledoverdraw.prg for accessing both the lab test results from the currentoffice visit being processed and the most recent result for each ofthose currently present. In addition, it takes advantage of the dualinvoice nature of the lab records. By storing the invoice from theparent office visit (or in the case were blood work was ordered from theemergency room, then the ER invoice no.) it becomes possible to locateand access the office visit (record) from which those `most recent,prior` lab tests were ordered. In that way the same salient clinicaldata in addition to just lab test results from the two separate officevisits for that out-patient can be coupled for comparison too and inthat way obtain a better idea of just why those lab tests from theoffice visit currently being processed were drawn, i.e. was there avalid reason based upon either a prior lab test result or some otherclinical condition.

It begins, as in step 3901, by searching the lab file for that recordlinked to the current office visit identified as meeting the `specialtype` criteria outlined in the discussion of overdraw.prg. Each field ofthat lab record is then tested for data (lab results). For each resultfound, the test name and, for abnormal results, the quantitative data isstored. A test is then made on a single letter on the parameter codesegment of that lab test field and if it indicates a prior test donethen a search is made for that lab record storing the most recent resultof that lab test for that out-patient. But, before accessing the data ofthat most recent lab test the first character of the invoice is tested.If it is from the emergency room as opposed to an office visit then anaccess of the results from that lab record is not done since the priorlab test was drawn in the atmosphere of acute care, etc. and it will beassumed that any lab test drawn during the office visit currently beingprocessed was justified as a follow-up of a test made previously butduring a potentially unstable clinical situation (i.e. ER). And as aresult a flag is also set to indicate that for use in the main programduring printing. However, if it is derived from a previous office visitfor that out-patient then the results and test date are accessed andtemporarily stored.

For normal current test results, normal prior test results and no priortest is available, the appropriate flags are set as indicators forinterpretation and resolution back in overdraw.prg prior to printing.

After the processing of that lab test result, the subroutine moves(increments) to the next lab test field of that current office visitbased lab record. If data is found then repeat of the above processinguntil the last (14th) field of that lab record, linked to the current`special` office visit record, has been tested. Then the variablesstoring all the accessed data, current and prior results and appropriateflag settings, are passed back to overdraw.prg for resolution,formatting and printing.

As in previous subroutines that access lab test data the method usedhere is virtually the same. The use of several `dedicated` variablesthat are for storing either separate aspects of each lab test result orthe equivalent in blank spaces, and the position of any test result inrelation to other test results is the same as thier relative positionsin the lab record. If there are actual results in any lab test fieldthen each of the variables are filled by a fixed amount of charactersthat are identical for each test but vary for each variable due to thedifferences in what data they store

Back in the main program, overdraw.prg, each of the variables arestepped through together when tested for the presence of data for eachlab test. When ever a test result is found each of the passed variableare accessed at the same relative position for the several aspects ofeach result and one detail line is then printed, with the number ofdetail lines dependent upon the amount of lab tests done during thattriggering office visit (record). ##SPC1##

I claim:
 1. A computerized out-patient primary care medical system forthe entry of clinical data stored into a database, said medical systemincludes;means for documenting up to three chronic, long term diagnosisin an out-patient office visit record, said record created during saidentry of data and said diagnosis represented on a source document by apartial code that consists of the last 4 digits of a full six digitchronic diagnosis code, means for determining the primary reason for anoffice visit through the use of either of two single letter codesobtained from said source document, said codes representing either achronic, long term diagnosis or an acute short term diagnosis, means fordocumenting the primary reason for an office visit, said primary reasonrepresented on a source document as a partial code that consists of thelast 4 digits of a full six digit chronic or acute diagnosis code, meansfor documenting any physical data noted during an office visit, saidphysical data consisting of signs and symptoms and represented on asource document as partial codes that consist of the last 3 digits of afull 5 digit physical data code, means for documenting office visittype, said type being either scheduled or unscheduled and represented byeither of two single letter codes present on a source document, meansfor documenting the clinical status of an out-patient during said officevisit, said status being represented by one of five possible singledigits that include a 1 indicating normality or baseline, 2 indicatingmild instability, 3 indicating serious instability, 4 indicatingimprovement from the out-patient's most recent office visit, and 5indicating that hospitalization was ordered during that office visit,means for checking entry of said clinical status according to a set ofrequirements listed on a screen during entry, said requirementsconsisting of entering a clinical status of 4 for any improvement insaid clinical status of an out-patient in comparison to thatout-patient's most recent visit and the mandatory entering of at leastone physical data item for any clinical status other than 1, means forupdating a related out-patient record during creation and said entry ofoffice visit record, said updating reflecting any changes in any of anout-patient's chronic diagnosis and said related record is anout-patient master medical record, means for identification of anout-patient master medical record, said identification being by entry ofan out-patient last name and full first name present on a master medicalrecord source document, means for dating the creation of a mastermedical record, means for documenting up to three chronic diagnosis ofan out-patient in said master medical record, alternate data sets usedby said documenting means consisting of either a partial code thatconsists of the last 4 digits of a full six digit chronic diagnosis codeas a direct entry means or a clinical group indicator and a fulldiagnostic text of said chronic diagnosis with or without a diagnosticcategory indicator as an indirect entry means of said documenting, meansfor identifying an out-patient laboratory test record that will storetest results, said identification being a nine digit number, means fordocumenting the date when laboratory tests were taken, said testsnumbering up to fourteen for each out-patient lab test record, means forassigning a special number to said lab test record, said special numberbeing an invoice and the most unique aspect of identification of saidlab test record, means for linking said lab test record to either of tworelated out-patient records, said records being either an office visitrecord or an emergency room record of said out-patient depending uponthe location from which the lab tests were ordered, means for enteringparameter or historical data with each current lab test result, saidparameter or historical data is in encoded form and represents acompilation of past results of any single lab test including chronicityof abnormality and a most recent result of that test whether normal orabnormal, means for recalling prior test results from different aspectsfor each current lab test result, said prior aspects include date andvalue of first abnormality, date and value of last abnormality,consistency of prior results, and the most recent result for aparticular test normal or abnormal.
 2. The computerized out-patientprimary care medical system of claim 1 wherein said entry of clinicaldata into a database office visit record further includes;means forentering an out-patient identification number from an office visitsource document, said number entered consisting of 9 digits, means forobtaining a special six digit number for said office visit record beingcreated, said number is referred to as an invoice and is said record'smost unique aspect of identification, and said means for obtainingincludes, means for adding one to a number being stored in a data fieldof the most recent office visit record created, said most recent recordis usually that of another out-patient on the database, means foraccessing a full six digit chronic diagnosis code from a chroniclong-term diagnosis table, and said means for accessing furtherincludes, means for first entering a 4 digit partial code from saidoffice visit source document, said partial code consisting of the last 4digits of a full six digit chronic diagnosis code, and further includesmeans for searching by said 4 digit partial code entered upon saidchronic, long-term diagnosis table, means for accessing up to two full 5digit physical data code from a physical signs table, and said means foraccessing includes, means for first entering a 3 digit partial code fromsaid office visit source document, said partial code is the last 3digits of a full 5 digit physical signs code, and further includes,means for searching by said 3 digit code entered upon a said physicalsigns table, means for accessing up to two full 5 digit physicalsymptoms codes from a physical symptoms table, and said means foraccessing includes, means for first entering a 3 digit partial code fromsaid office visit source document, and further includes means forsearching by said 3 digit number entered upon a said physical symptomtable, and means for writing the full 5 digit physical signs andsymptoms codes accessed to their appropriate data fields in said officevisit record being created, means for writing a full 6 digit chronicdiagnosis codes to one of three chronic diagnosis data fields, saidfield written to depends upon the clinical urgency or prognosis of thatchronic diagnosis in relation to any of the other two possible chronicdiagnosis of that out-patient that may also be entered, means foraccessing the primary reason for an office visit, said accessing meansfurther includes, means for entering a single letter code from saidoffice visit source document, and further includes means for thenentering a 4 digit partial code from said source document, said 4 digitpartial code present in a data field of said source document that isdesignated as said office visit primary reason, means for obtaining, ifsaid single letter code entered indicates a chronic diagnosis as saidprimary reason for said office visit, a full six digit code from achronic, long-term diagnosis table and means for obtaining, if saidsingle letter code entered indicates a short-term acute diagnosis as theprimary reason for said office visit, a full six digit code from anacute diagnosis table,and said means for checking the entry of saidoffice visit clinical status according to a set of requirements listedon a computer screen during said entry of clinical data furtherincludes, means for preventing the entry of a status 2 immediatelyfollowing a status 3 office visit record of that out-patient or a status1 immediately following a status 2, said prevention is for ensuring thata status 4 indicating clinical improvement intervenes first in bothcircumstances and further includes, means for preventing the entry ofclinical status other than 1 if there are no physical data partial codeson said office visit source document, and means for preventing thecreation of said office visit record if any of the prior said clinicalstatus conditions on said source document exists, means for checkingthat all of an out-patient's current chronic diagnosis are present onsaid source document for entry, and said means for checking furtherincludes, means for first testing if any chronic diagnosis data field onsaid source document is blank by absence of any data entered from saidfield and the corresponding field of that out-patient's master medicalrecord is also blank, and said checking further includes, means forwriting from said master medical record any chronic diagnosis of thatout-patient that is present but absent from the corresponsign data fieldon said source document to the corresponding data field of the newoffice visit record being created, said writing rectifys any ommissionof an out-patient's chronic diagnosis that should be entered but isabsent from said source document, and further means for testing if anychanges in any of an out-patient's chronic diagnosis are to be madeduring an office visit record data entry, and prior said testingincludes means for comparing a said 6 digit code of a chronic diagnosisaccessed for writing to a newly created office visit record to thatalready present in the corresponding field of that out-patient's mastermedical record, and further means for writing any differences foundbetween the two said corresponding data fields from the field positionof said newly created office visit record to the field position of thatout-patient's master medical record, said writing is for updating anychanges in an out-patient's chronic diagnosis to that out-patient'smaster medical record.
 3. The computerized out-patient primary caremedical system of claim 1 wherein said entry of clinical data into adatabase master medical record further includes;means for entering thefirst and last name of an out-patient from a master medical recordsource document, means for determining which of two methods, direct orindirect, are to be used for entering up to three chronic diagnosis intosaid master medical record, said method used depending upon which of twoalternate sets of data fields have been filled out on said mastermedical record source document, and means for direct entry, if abovesaid determining means finds just a 4 digit partial chronic diagnosticcode present on said source document, and said means for direct entryfurther includes, means for accessing by said 4 digit partial codeentered a full 6 digit code and its corresponding diagnostic text from achronic diagnosis table, means for indirect entry, if above saiddetermining means finds a clinical group indicator and a text of thediagnosis to be entered with or without a diagnostic category indicatorpresent instead on said source document, and said means for indirectentry further includes, means for displaying on a computer screen thecontents of a group of chronic diagnosis records from said chronicdiagnosis table that are restricted according to said clinical groupindicator entered from said source document and further restricted bydiagnostic category if that single letter indicator is also entered fromsaid source document, said display of record contents consist of boththe full six digit code and the text of each chronic diagnosis displayedand means responsive to the restricted display means for selecting fromsaid computer screen only the last 4 digits of the full 6 digit chronicdiagnosis code that corresponds to and is associated with the diagnostictext also displayed that matches the one present on said master medicalrecord source document, and means responsive to the selecting means forthen entering the said 4 digit partial diagnostic code corresponding tosaid text of chronic diagnosis code displayed that was found to beidentical to that existing on said source document, and means responsiveto entering means for accessing both the full 6 digit diagnostic codeand its corresponding text from said chronic diagnosis table by the said4 digit partial code entered, and further means for writing to anappropriate data field of said out-patient master medical record boththe said full 6 digit code and the diagnostic text accessed from saidchronic diagnosis table by said 4 digit partial code entered, and saidwriting completes the said indirect method of chronic diagnosis entry,means for determining if a previous master medical record is on file foran out-patient before said record is created and said data entered,means for informing a data entry operator of the current total aftereach of up to three chronic diagnosis for each out-patient is entered,means for checking the proper ordering by clinical urgency or prognosisthe relative data field positions occupied by each of up to threechronic diagnosis entered, and said checking means includes, means forcomparing the relative numeric values between the last 4 digits of thefull six digits of each chronic diagnosis entered, said value of thelast 4 digits of the primary field diagnosis should be less than thelast 4 digits of any secondary field diagnosis which in turn should beless than the last 4 digits of any tertiary field diagnosis and, meansfor re-writing any chronic diagnosis that is out of order in relation toany other chronic diagnosis for that out-patient into its correctrelative field position in said master medical record.
 4. Thecomputerized out-patient primary care medical system of claim 1 whereinsaid entry of clinical data into a database lab test result recordfuther includes;means for entering an out-patient identification numberconsisting of 9 digits means for entering the date of when said testswere taken, said date may be as much as two or three days after theywere ordered, means for determining the origin of said lab tests, saidorigin being either an out-patient office visit or an emergency roomvisit, and said means for determining includes, means for indicating bya single letter code entered whether or not said tests were orderedduring an office visit, means for accessing, if said determining meansindicates an office visit origin of said lab tests, a 6 digit code thatmost uniquely identifies that office visit record of said origin, andsaid origin, and said means for accessing includes means for finding themost recent office visit record for that out-patient, means foraccessing, if said determining means indicates an emergency room originof said lab tests, a 6 digit code that most uniquely identifies thatemergency room record of said origin, and said means for accessingincludes, means for finding the most recent emergency room record forthat out-patient, means for preventing entry of emergency room orderedlab test data in cases of poor patient compliance, and said means forpreventing entry includes means for determining if period of timebetween the emergency room visit and when test were actually taken ismore than a specified amount of days following said emergency roomvisit, means for entering first time lab tests for an out-patient ofsaid database, means for recalling prior lab test results for anout-patient who has current test results present for entry, and saidmeans for recalling includes, means for generating a list of selectionson a computer screen, each said selection enables obtaining any priortest result already on file from different, separate aspects thatinclude date and value of last abnormality, date and value of firstabnormality, most recent result for that lab test and the pattern orconsistency of a lab test's prior results, and said means for recallingfurther includes, means for displaying on a computer screen the priorresult of a lab test according to any of the prior said aspects selectedfrom said list of prior aspects generated, means for compiling saidprior aspects of results for any lab test into an encoded form foraccompanying the current quantitative abnormal result or a normal resultinto storage in said lab test result record, said compiled dataconstitute the parameter or historical data for indicating a combinationof past results of any lab test to complement the current result storedto said lab test result record, means for activating a customized dataentry screen for each of up to 14 lab tests, said customized screen isfor assigning each lab test result to a designated position for entry,means for creating a lab test result record for the entry and storage ofup to 14 different lab test results, means for linking said lab testrecord with either the source office visit record or the sourceemergency room record, said linkage based upon the dual invoice natureof each lab test result record wherein said lab test record containsboth a special 6 digit number unique and inherent to it and the special6 digit number unique to the source or parent record, whether officevisit or emergency room, representing from which said lab tests wereordered, means for assisting a data entry operator in the said compilingof said parameter or historical data into encoded form to accompanyingsaid current results into storage, and said means for assisting furtherincludes, means for instructing a data entry operator on how to selectfrom a number of possibilities 3 single letter codes for indicating, inthe case of an abnormal result, the three encoded elements of saidparameter data that consist, in the case of an abnormal result,chronicity of that abnormality, intensity of that abnormality and themost recent result for that test while in the case of a normal resultjust one encoded letter for indicating whether or not the most recentresult for that test, if present, is normal, and said means forinstructing further includes, means for displaying said instructionsincluding sample selections on a computer screen for data entry operatorreview during said entry of clinical data.
 5. A computerized out-patientprimary care medical database system for the processing and reporting ofclinical data includes;means for creating by a set of intermediaryroutines new, office visit-derived intermediary records for the storageof office based clinical data in compiled form; and said creating meansincludes, means for detecting by out-patient diagnostic category earlyand possibly unnecessary scheduled office visits, said diagnosticcategory established and defined by either an individual chronicdiagnosis or the combined value of up to three chronic diagnosis of anout-patient present in a said office visit-derived record in referenceto a table of chronic diagnosis sorted in descending order by clinicalurgency or prognosis, means for detecting by diagnostic categoryconsecutive unscheduled out-patient office visits, means for determiningwhether or not said early scheduled office visits were clinicallyjustifiable, said justification being either absolute or tentative,means for detecting by diagnostic category 3 types of protractedillnesses, said illnesses represented by a continuous string of officevisit-derived records of an out-patient that all contain a clinicalstatus indicator other than 1 and each of said three types of protractedillnesses differing by initial level of severity, means for determiningif any, and type of, physician intervention or action occured duringeach office visit included in any of 3 said types of protracted illnessprocessing for an out-patient, said types of actions include newmedication, medication changes, specialty referrals, lab tests orderedand office injections of medication including by what route,intramuscular or intravenous,and said reporting of clinical dataincludes, means for printing by said diagnostic category from saidoffice visit-derived records the physical, medication change andlaboratory test results separately but from the same office visit, meansfor printing of clinical data that may reveal the overusage of officevisit based lab tests ordering, said overusage because of the absence ofany documented problems during those office visits when said tests wereordered, and said reporting of clinical data further includes; means forquerying of said out-patient database summary-type and narrowlyformulated out-come based clinical data for computer screen display. 6.The computerized medical database system of claim 5 wherein said meansfor the querying of out-patient clinical data in a narrowly formulatedand summary form includes;means for accessing from several related andlinked files different types of clinical data for each out-patient, saiddata combined to define and focus upon distinct aspects of ambulatory,primary care medicine and includes, means for determining by databasedoctor if a disproportionate number of database out-patients with aparticular chronic diagnosis are assigned to and under the care ofparticular primary care doctor in relation to other primary care doctorson that database, and said means for determining includes, means forentering a doctor name and the full text of a particular chronicdiagnosis, and means for responsive to the entering means for accessing,by said doctor name and diagnosis entered, out-patients on the databasewho are both under the care of that doctor and who have that particularchronic diagnosis, and said accessing means further includes, means forcounting amongst a database file both the number of said patients withthat diagnosis, and if any, the number of those patients who are underthe care of that doctor whose name was entered, said database file thatsaid count is made on is the master medical record file, and furthermeans for computing the percentage of all database out-patients withthat chronic diagnosis, and means for computing what percent of thatpercentage consists of those out-patients who are also under the care ofthat doctor whose name was entered, and further means for displayingsaid computed data on a computer screen, said display consisting of bothintegers and fractions,and said means for querying out-patient databasedata further includes, means for reviewing both the medication changeactivity and the physical data observed amongst out-patients with achronic cardiac diagnosis during office visits in which they wereobserved to be very symptomatic, said very symptomatic being indicatedby a clinical status of 3 being found in that data field of office visitrecords, and further includes means for entering just the name of adatabase doctor, and further means responsive to the entering means forselecting a set of office visit records by both a clinical status of 3and the presence of a chronic cardiac diagnosis and further means foraccessing the literal text corresponding to the encoded physical datastored in said set of office visit records selected,said literal textaccessed from a physical signs and symptoms table and said means foraccessing includes, means for searching said physical signs and symptomstables by codes present in physical data fields of an office visitrecord selected, and means for accessing medication activity frommedication activity records linked to said office visit recordsselected, said linkage is by a special six digit number unique to eachoffice visit record and also present in each said medication activityrecord linked, and means for combining said physical and medicationactivity from each said office visit record selected with other salientoffice visit data, said salient data includes out-patient I.D. numberand data of office visit and medication activity reported can include anaddition, change, deletion or an injection of medication during saidoffice visit, and means for displaying on a computer screen saidclinical data combined from each said office visit record selected firstby doctor name entered and then by a clinical status of 3 and thepresence of at least one diagnosis that is a chronic cardiac oneand,said means for querying out-patient clinical database data furtherincludes, means for obtaining prior lab test results for a databaseout-patient, said said results can be presented by either individual labtest results from any of several prior aspects or a group of testsordered during the same office visit, and means for entering anindicator for choosing which of the two above types of presentation ofdata the user desires and, means for determining which said choice wasentered and means for entering, if said group of lab tests from anoffice visit was selected for viewing, an approximate date for thatoffice visit and further means for re-entering another date if saidapproximate date previously entered is incorrect until a correct datefor the desired office visit is entered and, means for accessing therelated lab record linked to the office visit of the correct dateentered, and said accessing means includes means for searching anout-patient lab test result file that contains a lab record storing aspecial six digit number that most uniquely identifies that office visitrecord it is linked to and also found in said lab record, and means forcombining all the lab test results from said office visit along witheach's parameter or historical data with other salient data from eachoffice visit, said salient data includes patient name, date of visit andthe chronic diagnosis of said out-patient, six digit number identifyingthat office visit, date lab tests drawn and the six digit numberidentifying that lab record and further means for selecting one at atime from amongst 14 lab tests if prior said choosing means indicates adesire to view individual test results instead of a group of testresults from the same office visit, and further includes means forgenerating a menu listing several prior aspects from which to viewprevious results of a particular lab test of an out-patient currently onfile, said prior aspects include the date and value of both the firstand last abnormal result for that test if present, result of most recenttest, consistency of results for that test and both the highest andlowest abnormal value of that particular lab test, and further includesmeans for obtaining from that out-patient's lab test records any of said14 lab test results depending upon what selection from said menu listingof prior aspects of results was made, and said means for obtaininginclude means for searching back on said out-patients lab recordsarranged in chronological order to access a said record or recordsaccording to which said prior aspect of results was said selected fromsaid menu listing, and means for combining said individual test resultsfrom any of said prior aspect from said menu listing with other salientdata, said salient data includes patient identification, date of test inquestion, first abnormal result and date as a reference, and furthermeans for displaying said combined data for computer screen review, andsaid means for querying clinical data from a database further includes,means for documenting if there is any impending or actual medicationinduced toxicity of any databaseout-patient who is currently onmedications, said said toxicity indicated by an abnormal result of a labtest that is known to be an especially sensitive marker for the toxiceffects of a particular medicine and the degree of abnormality relatedto the level of toxicity, and said means for documenting furtherincludes, means for entering both a database doctor name and amedication name, and means for accessing by doctor name and medicationname entered those database out-patients who are taking that medicationand are under the care of that doctor whose name was entered, and saidaccessing means includes means for searching on a database file by saiddoctor name entered, said file is the master medical file that storesboth the doctor name and the current medications each out-patient is onalong with the dosages, and means for listing by both patient I.D.number and name those out-patients taking that medications, the amounts,who are under the care of that doctor whose name was entered, means forinforming an operator if said doctor whose name was entered does nothave any patients currently taking that medication entered, means forselecting from alist of 14 lab tests, said lab test selected is onepresumed by user to be specific for indicating any existing toxiceffects from said medication whose name was entered, and further meansfor selecting from any of said out-patients listed by name and I.D. no.said selection is by entering the I.D. no. listed alongside any patientname also listed on a computer screen, means for combining all dataaccessed for that out-patient selected, said data includes all theresults of that lab test currently on file for that out-patient selectedin chronological order alongside the medication in question and theamount of that medication that out-patient is currently taking, andmeans for displaying that data on a computer screen for user review,said review for the purpose of monitoring for any medication inducedtoxicity.
 7. The computerized medical database system of claim 5 whereinsaid means for the data processing of a said intermediary routine forthe detection of of an early and possibley unnecessary scheduled officevisit by diagnostic category further includes;means for identifying twoconsecutive minimal-clinical-activity or uneventful types of officevisit records for a same out-patient and whose difference in days orlength of time between said consecutive office visits is less than thatset for that out-patient's diagnostic category for any two uneventfulvisits occuring consecutively for an out-patient belonging to saidcategory, and said uneventful or minimal-clinical-activity type, eitherunscheduled or scheduled, is defined as having a clinical status of 1indicating a normal or absence of change in baseline clincal condition,a chronic diagnosis as the primary reason for said office visits andtotal absence of any physician action or intervention during either ofsaid two consecutive office visits, and another said intermediaryroutine that includes, means for identifying an unscheduled office visitof the minimal-clinical-activity type that is followed by a scheduledoffice visit by the same out-patient that is also of theminimal-clinical-activity type that occurs within the time interval forminimal-clinical-activity types by that diagnostic category, saidscheduled type therefore being early and possibley unnecessary and meansfor determining if said early and possibley unnecessary scheduled typeof uneventful office visit is clinically justifiable, said justificationmay be absolute or tentative and further includes, means for accessing aset of other related out-patient records in separate files whose datarepresent distinct but related aspects of out-patient primary care, saidother records includes emergency room, lab tests, out-patient treatmenthospital and surgery files and further means for identifying in any ofother related records of that out-patient with an early scheduled officevisit of the minimal-clinical-activity type an indication of activityoccuring between the two said consecutive office visits of theminimal-clinical-activity type, said activity or event may serve tojustify the second early consecutive office visit of theminimal-clinical-activity type if said actvity or event met certainclinical criteria and further means for determining if any saidjustification can be found in any of said other related out-patientrecords and includes, means for finding an interim emergency room recordof that out-patient dated within the interval of time between both saidconsecutive office visit records of the minimal-clinical-activity typeand further means responsive to the finding means for obtaining the sixdigit number identifying said interim emergency room record, said sixdigit number identifying the source of the potential justification forsaid early, second office visit of the minimal-clinical-activity andscheduled type, and means responsive to the obtaining means for settingan indicator if there is an indication within said interim emergencyroom record that either an immediate office visit or a hospitalizationwas advised at the time of said emergency room visit for thatout-patient, said indicator set will establish absolite justificationfor that out-patient's early, consecutive office visit of theminimal-clinical-activity or uneventful type, and said means fordetermining actual or tentative, potential justification for an early,consecutive office visit of the uneventful type further includes, meansfor finding an interim hospitalization record of said out-patient thatindicates a stay between said two consecutive office visits of theuneventful type, and further means responsive to the finding means forobtaining a six digit number from said hospital record that at leastidentifys the source of a potential or tentative clinical justificationfor said early, second office visit and means responsive to theobtaining means for setting an indicator if the discharge diagnosis ofsaid hospital record is the same as the primary reason for the early,consecutive office visit of the uneventful type for that out-patient,said indicator setting establishing absolute justification for thatout-patient's early, scheduled visit of the uneventful type, and saidmeans for determining clinical justification further includes, means forfinding an interim lab test record of said out-patient that was datedbetween the two consecutive visits of the minimal-clinical-activity typeand means responsive to the finding means for obtaining a six digitnumber identifying said interim lab test record, said six digit numberrepresenting a potential or tentative source of clinical justificationfor the said early consecutive office visit of the uneventful orminimal-clinical-activity type and additional means responsive to theobtaining means for setting an indicator if the parameter or historicaldata that is encoded and accompanies the actual result of that lab testindicates any change from the previous result for that test, saidindicator setting establishing absolute justification for an early,second scheduled office visit of the minimal-clinical-activity oruneventful type and said means for determing any clinical justificationamongst that out-patient's other related clinical database files furtherincludes, means for finding an interim out-patient treatment recorddated between the two said office visit records of the uneventful typeand means responsive to the finding means for obtaining the six digitnumber of that said treatment record, said six digit number identifyingthat record as at least a potential or tentative source for clinicaljustification for the early, second office visit of the uneventful typeand further means responsive to the obtaining means for setting anindicator if the said treatment record contains an indication by thetherapist that the out-patient's condition for said therapy is gettingworse, said setting of the indicator establishes absolute justificationfor said early, second uneventful scheduled office visit, and said meansfor determining any clinical justification further includes, means forfinding a most recent surgery record of that out-patient and meansresponsive to said finding means for determining the date, category andtype of surgery performed on said out-patient, and additional means forobtaining a six digit number uniqely identifying said surgery record ifsaid surgery type is from a major surgical catergory, said six digitnumber serves as at least potential or tentative justification for theearly, second scheduled visit of the minimal-clinical-activity oruneventful type, and further means for setting an indicator if saidsurgery was dated within a particular time interval from the saidsecond, early uneventful visit of the scheduled type said indicatorsetting establishing absolute justification and means responsive to saiddetermining means for obtaining a six digit number if said surgery isfrom the moderate surgical category type, said six digit numberestablishing a potential or tentative source for clinical justificationand additional means responsive to said obtaining means for setting anindicator if said moderate surgery type occured within a time intervalfrom the second, early visit of the uneventful type that is lesser inamount that the time interval for the said major surgical category type,said indicator setting establishing absolute clinical justification, andadditional means responsive to said determining means for obtaining asix digit number of said surgery record if said surgery is of a minorcategory and the date of said minor surgery is within a lesser timeinterval from the second, early uneventful scheduled office visit thanthat of the major surgical category type, and means responsive to theobtaining means for setting an indicator if the clinical group indicatorof the said minor surgery type is the same as that of the primary reasonfor the early, second scheduled office visit of the uneventful type forthat out-patient, said indicator setting establishing absolutejustification on the basis of said past minor surgery because theclinical group or organ system involved in said minor surgery is thesame as the primary reason for the said second, early office visit ofthe scheduled and uneventful type, and additional means for creating anew office visit-derived record in an intermediary file for each earlyconsecutive scheduled office visit that followed either an unscheduledor scheduled uneventful type for the same out-patient, and meansresponsive to said creating means for writing to said newly createdoffice visit-derived record a variety of pertinent clinical data incoded form, means responsive to said creating means for transferringdata from said second, early scheduled uneventful office visit to saidnewly created office visit-derived intermediary record, said written andtransferred data includes I.D. number of out-patient, date of secondvisit, special six digit number identifying said visit, data indicatinga potential or actual clinical justification of said visit, thediagnostic category of the out-patient and an indicator for encoding thename of the intermediary routine that processed said out-patientrecords, and means for identifying every successive unscheduled officevisit by an out-patient that follows a first one identified, meansresponsive to prior said identifying means for creating a new officevisit-derived intermediary record for each successive unscheduled officevisit record of an out-patient that is found beyond that out-patient'sfirst one, and means for writing to said newly created officevisit-derived intermediary record a variety of pertinent data in codedform, and means for transferring data from each of said successive,unscheduled office visit record to the said newly created officevisit-derived record, said written and transferred data includes whatnumber in succession each unscheduled visit represents, out-patient I.D.no., date of visit, special six digit number most uniquely identifyingthat office visit, encoded name of intermediary routine that processedsaid record and diagnostic category of that out-patient.
 8. Thecomputerized medical database system of claim 5 wherein said means forthe detection, by diagnostic category, of three types of protractedout-patient illnesses that differ by initial level of severity furtherincludes,means for detecting a minimum number of consecutive officevisit records of an out-patient that represent only a mild, fluctuatingillness in which the clinical condition of said out-patient has notreturned to normal or baseline but hasn't yet become serious, saidclinical condition reflected by a clinical status of 2 with any one ofthe contiguous office visit records of that out-patient within saidminimum number being possibley a 4 indicating an improvement from theprevious visit and said minimum number of records being 3, and meansresponsive to the detecting means for further detecting all additionalsubsequent office visit records for that out-patient that are alsoeither a 2 or 4 clinical status, means for detecting a first officevisit record whose clinical condition indicates a serious, prehospitalstage, said condition represented by a clinical status of 3, and furthermeans responsive to prior detecting means for the further detection ofall antecedent and subsequent contiguous office visit records of thatout-patient in which anything other than a baseline or normal clinicalstatus of 1 is found, means for detecting the first office visit recordof any out-patient in which the clinical status is anything other than a1, and further means responsive to the prior detecting means fordetermining if a most recent office visit record of that out-patient ispresent, said most recent record would have a clinical status of 1 andserve as a reference for comparing data with that out-patient'ssubsequent non-1 clinical status records, and means responsive to priorsaid determining means for the further detection of all subsequent,contiguous office visit records for that out-patient after said firstoffice visit record of a non-1 clinical status that is also anythingother than a 1 clinical status, and means responsive to any of 3 priorsaid detecting means for the accessing of all said office visit recordsdetected as part of a said protracted, continuous out-patient illnessand means responsive to any of 3 said prior detecting means fordetermining what, if any, physician intervention or action occuredduring each office visit whose record has been said detected as part ofany of 3 said protracted out-patient illness, said types of physicianintervention may include new medication, medication change, lab testordering, specialty referrals and office injections of medications, andmeans responsive to determining means for computing a decimal numberbased on which, if any, of 4 fields in said office visit records are setto true, said fields correspond to each of said physician actions exceptthat of medication injection and any said number computed out of 16possible ones correspond to a particular action or combination of saidphysician actions including zero which indicates no physician action orintervention at all, and means responsive to the computing means fortranslating said number computed into one of sixteen possible singleletter codes, said single letter is for indicating which, if any, typeor combination of types of said physician actions occured during any ofsaid office visits whose records were part of any of 3 said protractedout-patient illnesses, and means for determining if an injection occuredduring any said office visits, means for creating a new, officevisit-derived record in an intermediary file, said new recordcorresponding to each office visit record detected as part of any ofsaid 3 types of protracted out-patient illnesses, and additional meansresponsive to the creating means for writing to each new record createda compilation of data derived from an office visit record detected assaid part of any of 3 types of protracted out-patient illnesses, saiddata includes out-patient identification, date of visit, office visitidentification, a single letter for indicating which of 3 said types ofprotracted illnesses that office visit record was detected as part of, asingle letter for indicating what, if any, type or types of physicianactions occured during said visit, and any medication injection that mayhave occured and by what route during that visit.
 9. The computerizedmedical database system of claim 5 wherein said means for the separateprinting of physical, medication and laboratory test data from the sameoffice visit further includes,means for selecting an intermediary fileof office visit-derived records by out-patient diagnostic category,primary reason for an office visit and a cut-off date, said recordsderived from office visit records detected as part of any of 3 saidtypes of protracted out-patient illnesses and said primary reason beingeither an acute, short-term or a chronic, long-term diagnosis, and saidmeans for the printing of office visit based physical data includes,means for accessing from said selected office visit derived records upto physical data codes reflecting up to 2 signs and two symptoms, saidcodes consisting of 5 digits with the first indicating theclinico-pathological group or organ system of those signs and symptomswith the last three digits being its most unique aspect ofidentification, and further means for accessing from physical signs andsymptoms tables the literal text corresponding to said codes by the lastthree digits of said 5 digit codes present in said office visit-derivedrecords, and means for accessing a master medical record belonging tothat out-patient of said office visit-derived records said selected,said master medical record is linked to any of said office visit-derivedrecords by out-patient I.D. no. means for printing out background datafor each out-patient whose office visit-derived records were saidselected, said data is heading data that appears once for eachout-patient whose physical data is for printing and includes up to threechronic diagnosis for that out-patient, date of birth, date of lasthospitalization and full name, and means for printing the literal textof up to four physical data elements, said elements consist of saidliteral text of signs and symptoms from each said office visit-derivedrecord selected, and means for printing a message if any said officevisit-derived record that was selected did not contain any physicalsigns, symptoms or both, and means for printing other clinical data fromeach office visit-derived record to accompany the literal text of saidphysical signs and symptoms, said other data includes date of visit, sixdigit number most uniquely identifying said visit, and the text of theprimary reason for said visit, and means for printing, in the case of achronic diagnosis as the primary reason for said visit, the bloodpressure reading from said visit in addition to the physical data, saidblood pressure printing is restricted to those out-patients who haveeither a cardiac, neurological or a vascular basis for that chronicdiagnosis that served as the primary reason for said visit, and meansfor printing, in the case of a chronic diagnosis as the primary reasonfor an office visit, additional data with each out-patient's last officevisit derived record that has been selected for said printing, saidadditional data is for indicating whether or not that particularprotracted illness has been terminated and that out-patient has returnedto a normal or baseline clinical status of 1 and whether or not ahospitalization has occured by the time of said cut-off date,and saidmeans for the reporting of office based laboratory data includes, meansfor determining if laboratory tests were ordered during an office visitwhose record was detected as part of any of 3 said types of protractedout-patient illnesses, and said means for determining further includes,means for testing in an office visit-derived record for the presence ofone several possible single letter codes, said codes for indicating iflab tests, alone or in combination with other types of physicianactions, were ordered during that visit, and means responsive to saidtesting means, if said means indicates the ordering of lab tests, foraccessing a six digit number from that office visit-derived record, saidsix digit number most uniquely identifies that office visit and is alsofound in a lab record linked to that office visit-derived record, andmeans for accessing from said linked lab record all test results presentalong with each lab result's encoded parameter, said encoded parameterdata reflects and is derived from that lab test's track record of pastresults for that out-patient and includes duration of an abnormality,intensity of the current abnormality and most recent result if present,and means for accessing a master medical record for each out-patientincluded in said office visit-derived record selection, and means forprinting background data once for each out-patient whose officevisit-derived records were said selected for said lab test resultreporting, means for printing the results of said lab tests along withthe literal text of each of the three encoded elements of the parameterdata that accompanies each test result, means for printing the normalresults of any lab test along with a remark about the most recentresult, if present, for that test, means for printing other clinicaldata from that office visit to accompany the lab test data from thatvisit, said data includes date of visit, six digit number most uniquelyidentifying that visit, date lab tests done and the primary reason forthat visit, acute or chronic diagnosis, in text form,and said means forthe reporting of office based medication data includes, means fordetermining if an oral medication dosage change occured during an officevisit whose record was detected as part of any of 3 prior saidprotracted out-patient illnesses, and said means for determiningincludes, means for testing in an office visit-derived record for thepressure of one of several possible single letter codes, said codes arefor indicating if medication dosage changes, alone or in combinationwith other said types of physician actions, were done during said officevisit, and further means for accessing, if prior determining meansindicates a medication dosage change, that out-patient's first medicineactivity record on file, and means responsive to prior said accessingmeans for locating that out-patient's most recent medicine activityrecord on file, and said records may store up to three medications whichmay all have undergone a dosage change during said office visit, andmeans for testing each of three data fields in said most recent medicineactivity record for an indication that a dosage change had been made forany of three medicines that may be stored, and means for finding foreach medicine that was found to have undergone a said dosage change insaid most recent medicine activity record the most recent prior amountof that medicine that out-patient was on whether or not it was also anamount changed to or a first amount as a new medication, said prioramounts for any of up to three medicines that underwent said change maybe found in up to three different prior medicine activity records forthat out-patient, and means responsive to the previously said prioramount finding means for accessing both current amount or amount changedto and the most previous amount or the amount changed from for each ofup to three medications that may have been found to have undergone saiddosage change during said office visit and are now present in saidlatest medicine activity record, and further means for accessing fromsaid latest medicine activity record a 5 digit code, said codeassociated with each medication that underwent said dosage change, andfurther includes, means for searching a medicine inventory table by said5 digit code to obtain the generic name text of each medication found tohave undergone said change in said latest medicine activity record,means for accessing a master medical record for each out-patient whoseoffice visit-derived records were said selected, and means for printingbackground data once for each out-patient as heading for said medicationdata reporting, and means for printing up to three medication dosagechanges, both amounts changed to amounts changed from and expressed ineither grams or tablets per day, and further, means for printing otherdata from each office visit with said medication change data, said otherdata includes six digit number identifying said office visit, date ofoffice visit and primary reason for that office visit, and means fordetermining if any data errors are present, said error might be in theabsence of a medicine activity record associated with that office visiteven though a said single letter code is present for indicatingmedication activity during that office visit, and means for printing amessage indicating said error is present, and means for printing if nomedication activity occured during any office visit.
 10. Thecomputerized medical database system of claim 5 wherein said means forthe printing of clinical data that may show the overusage of officevisit based lab tests further includes,means for selecting a set ofout-patient office visit records according to four clinical criterion,said criterion consists of a normal or baseline clinical status of 1indicating an absence of any disease activity or change in anout-patient's usual condition, a chronic diagnosis as the primary reasonfor that office visit, the office visit is of the scheduled type andyet, despite these 3 mentioned criteria that indicate an otherwiseunremarkable clinical situation, the ordering of lab tests was stilldone as the fourth criteria, and means for accessing from an officevisit record selected by prior said criterion data that links thatrecord to a laboratory record storing the results of said lab testsordered, said linking data is a six digit number that most uniquelyidentifies that office visit record selected and is also found in thatlab record linked, and means responsive to said accessing means forobtaining all of said test results ordered during those office visitswhose records were said selected, said lab tests ordered from saidselected office visit records are herein referred to as a first set oflab tests, and further means for determining if there are any priorresults on file for that out-patient for each of the first set of labtest results, said prior test results that correspond to each of thesaid first set of test results may each be found in different prior labrecords for that out-patient and said prior test results for each ofsaid first set of test results are herein referred to as the second setof lab test results, and means responsive to prior said determiningmeans for searching back on that out-patient's previous lab recordsuntil any most recent prior result of that test for that out-patient isfound for each of said first set of lab test results from each of saidoffice visit records selected, and further means for obtaining, ifpresent, a most prior test result for each of said first set of testresults ordered during said visit whose records were said selected, andsaid prior lab test results for each of said first set of resultsordered from an office visit whose record was said selected are hereinreferred to as second set of lab test results but each of which may havebeen obtained from a different prior lab record since any of said prioror second set of lab test results may have been ordered during adifferent prior office visit for any out-patient, and means forpreventing said accessing of any of the said second set of test resultsif any of those prior test results were ordered during an emergency roomvisit by that out-patient, said emergency room visit is, by its verynature and unlike an office visit of the said selected type, isautomatically considered significant enough to obviate the need tojustify any lab test ordered during even an office visit of saidselected type as long as that prior test was ordered during an emergencyroom visit, and said means for preventing access further includes, meansfor testing if the first character in a field of a lab test record thatis storing any of said most prior or second set of lab test resultsbegins with an E instead of an O, said character E indicating that saidtests were ordered during an emergency room visit and not an office one,means for accessing a master medical record for each out-patient whoseoffice visit records were selected by said criterion, and meansresponsive to said accessing means for printing once for eachout-patient whose office visit records were selected salient data asheading, said salient data includes last name of the out-patient doctor,a code indicating the name of the processing routine, last name and I.D.no. of the out-patient date of birth of out-patient, the primary chronicdiagnosis of that out-patient and date of last hospitalization, andmeans for printing with each office visit record selected for anout-patient some identifying data, said data includes the six digitoffice visit I.D. no, primary reason for that office visit, date ofoffice visit and date lab tests drawn that were ordered from said officevisit, and means for accessing for each of said second set of prior labtests that prior office visit during which each of said second set oftests were ordered, said prior tests may be from different prior officevisits of that out-patient means for printing together in coupled formboth the first set of lab tests from selected set of office visitrecords and the second set of the same lab test results for anout-patient, and further means for printing other data from each prioroffice visit during which each of the second set of prior lab tests forthat out-patient were ordered, said data includes primary reason duringeach office visit and the clinical status of the out-patient during thatoffice visit in order to enable determining the clinical need forordering said tests from said selected office visit records by comparingthe data printed together in coupled form.
 11. For use in a computerizedout-patient primary care medical database systemmeans for the automaticclassification of out-patients into one of three chronic diagnosis-basedclinical diagnosis categories through the use of a predefinedconsensus-based reference table of chronic diagnosis arranged accordingto the relative prognosis or clinical urgency of each, said referencetable divided into three diagnostic categories with each rankedhierarchically in relation to the other two and for classifying saidout-patients depending upon the diagnostic category location of up tothree chronic diagnosis any out-patient may have in relation to saidreference table, and said means for the automatic classification furtherincludes, means for creating an out-patient master medical or firstoffice visit record, said record creation occuring during a data entryroutine for either of said record type which then immediately confersupon an out-patient of that record the attribute of classification intoone of said diagnostic categories, and means for recognizing saidclassification of each out-patient by said database system during theexecution of data processing instructions, said instructions identifyeach out-patient record, master medical or office visit, as belonging toone of three said diagnostic categories depending upon the combinedvalue of up to three chronic diagnosis found in said record typesdetermined by thier relative position in said reference table of chronicdiagnosis, and said recognizing means includes, means for checking bysaid data processing instructions an encoded letter present in eachchronic diagnosis that is present in any out-patient record of priorsaid types, said encoded letter present in a fixed position in eachchronic diagnosis and for indicating to which of three said diagnosticcategorys of said chronic diagnosis reference table that chronicdiagnosis belongs to.